Tag Archives: java

Functional programming in the enterprise world

Recently I have been heavily using Apache Spark. For those of you who don’t know Spark is a very powerful system for working with data and parallel that is written in the Scala language. Scala is not new, but certainly on the “newer” end of the spectrum. Today new languages are coming out all the time so 12 years is fairly long. What many people find attractive about Scala, at least I do is the fact that it runs on the popular JVM. In fact a developer may be able to write code in Java and interact with code that was written in Scala. The challenge is striking the balance between closeness to Java and still providing whatever it is that the creators of the language hope to achieve.

I am a big believer in Object Oriented software design and development. I’m not saying that every project in the world needs to be written exactly the same, as they all have different requirements. I will say that for enterprise software the level of adaptability is truly best achieved with levels of modularity as well as abstraction. In truth, if you can achieve the principles that an enterprise architect looks at in a technology it may be something to be considered. In the past languages like LISP such as Haskell, were never geared towards the enterprise as their mathematical background and dynamic typing didn’t fit the bill for the type of type safety compilation and code reuse that has been found in other enterprise technologies. In general I like languages that aim for simplicity but at the same time aren’t overly opinonated. I recently read a rant about the Go language for the lack of support of assertions because the language creators felt that people used assertions incorrectly, not like Java chose to avoid pointers because of their inherit nature to cause errors. This is an example of a language being dumbed down or muted, with that said I really like many aspects of Go.

I’ve read a number of articles about so called “veteran” developers who have ditched OOP to embrace some sort of functional language. Complaining that the design principles of OOP aren’t applicable and don’t work. I even read recently that a college professor from Carnegie Mellon removed OOP from the syllabus for freshman. I don’t necessarily think that is too awful, but I do think problem decomposition that one would do when designing an OOP system is not only very helpful but also useful. Not everything easily fits into a “map” or a “reduce”. I can’t speak for all people, but I think that OOP is more natural to the domain than functional. If you truly understand the domain and how to break apart a problem into single scoped entities you will find simplicity and elegance.

With that being said, I think that for parallelism functional programming has always been faster and more efficient. I do however think that there is room to bridge the gap. Scala is a multi-paradigm language, not just functional. I believe it is that aspect that can truly bring something special to the table. Technologies like Spark still require a more or less functional approach. There are layers like Dataframes and graphs that attempt to abstract some of the functional aspects from the developer. What I haven’t yet seen is what Hibernate and other ORM technologies did for SQL, with respect to large scale functional parallelism. I think once we bridge that gap that will be the holy grail for enterprise software. I look forward to seeing how these technologies continue to evolve and mature.

Java Scripting Vulnerabilites

Recently I had to look into processing user inputted expressions which would enable a user to insert control flow logic into a workflow depending on whatever criteria they wish. We are already using JBoss’s jBPMN which is an implementation of BPMN, a standard workflow schema. It is a stable, trusted and widely used tool in the enterprise community.

jBPMN allows the workflow to have “constraints” where you may inject variables or really whatever you wish and supply either Java code or MVEL expressions to evaluate and ultimately control the flow of the workflow. MVEL is just a subset of Java and provides a nice “scripting” feel while maintaining access to all Java objects and classes without the verbosity of Java. With that said, both Java and MVEL are subject to malicious code should as much as if you were running that code directly not in an interpreter. My first thought was that it was likely that either on the MVEL layer or on the jBPMN layer there are some restrictions added in to safeguard the application and the underlying system. I was wrong. I was able to invoke RunTime.getRuntime().exec("rm -rf /") which will obviously yield some pretty devastating results. I’m assuming that jBPMN was never intended to be written for the purposes of allowing external parties to invoke their own code. However, that is precisely what I needed to accomplish without sacrificing the security of the system.

I looked into using Rhino (https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Rhino, https://docs.oracle.com/javase/7/docs/technotes/guides/scripting/programmer_guide/) which is the standard scripting engine available in Java 7. Rhino has now been taken out of the spotlight as Java 8 offers the new and improved Nashorn JavaScript engine. I didn’t evaluate Nashorn regarding security concerns as the project this was related to was limited to using Java 7. I was able to invoke a slightly differently command as I did with Java/MVEL. With Rhino I needed to provide the entire package name, but the outcome was ultimately the same; I was able to invoke the exact same commands as I did earlier.

I looked around and found this blog post (http://maxrohde.com/2015/08/06/sandboxing-javascript-in-java-app-link-collection/) which led me to a simple little library (https://github.com/javadelight/delight-rhino-sandbox). It combines a number of things including the initSafeStandardObjects() method which removes the Java connection entirely. This library also provides some easy ways to still inject desired objects and data.

The result is with a little bit of code I am able to invoke the sandboxed JavaScript within the jBPMN evaluation and having the inputted script written in JavaScript. All I have done is made it that the constraint evaluation will yield a separate evaluation which is then used to return a boolean value indicating whether or not the corresponding step should be invoked or not. In reality this sort of logic would not be limited to JavaScript via Rhino. Once we are separating the execution from reliance on what jBPMN supports there isn’t anything stopping us from supporting any script language that may be invoked in the JVM or on the host machine.

The end goal is we were able to leverage the stability and power of jBPMN without sacrificing our systems security.