Glosario KW | KW Glossary
Ontology Design | Diseño de Ontologías
Special | A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | ALL
J (OPEN SOURCE)
J (WEB SERVICES)
Java 8 vs. .NET
Functional programming in Java 8 vs. .NET: What you need to know
by Tom Nolle
The 'which is better' debate over .NET and Java has been going on forever. Expert Tom Nolle weighs in on which is the better choice if your goal is functional programming.
Probably the most enduring and multifaceted debate in all of software development is whether the Java or Microsoft .NET platforms and ecosystems are best. Both have enthusiastic and loyal supporters, but there's also a large, uncommitted community that could swing the balance decisively.
Every time something new comes along, it presents an opportunity for such a swing, and functional programming is no different. Is functional programming in Java 8 better than .NET, or the other way around?
Modularity and composability are the goals of all modern software design. Historically, they've been achieved using object-oriented or service-oriented programming, where functions are built as independent components and composed using specified interfaces and rules. Complex functions would necessarily have complex interrelationships, making open composition difficult.
Start by doing the math
Functional programming in Java 8 or anything else is an almost-mathematical approach to the problem, where logic is built by assembling functions built, so the input to one is always the output of another. Variables are immutable, and only a function can provide a variable result. Essentially, logic is a function pipeline built from what are called lambda expressions. The concept has been around in various forms for decades, but it's becoming more popular as modularity and composability become more and more important. Functional programming in Java 8 is supported, and so .NET programmers want to know how they can adopt the model.
Is functional programming in Java 8 better than .NET, or the other way around?
There are two basic paths to functional programming in .NET: Programmers can use C# and evolving features to support lambda functions, or they can use the open source functional language Microsoft announced in 2010 -- F#. Most users of F# say they also use C#. And, in many cases, they use it within the same application. Many programmers try to stay with C# if they're familiar with it, but most who have made the transition to F# would agree it's the better choice. And it's wise to assume if you're going to do .NET functional programming, you're going to do it in F#.
For Java users, particularly those focusing on functional programming in Java 8 with all of its advances, the C# path is the most comparable. You can write functional code in C# and use constructs that enforce some of the key behaviors of functional programming -- like immutable variables and statelessness -- but you can also write object-oriented programming or imperative programs. This is comparable to Java 8's approach.
Learn about F#
F# is different, because it's one of the few languages that is designed for functional programming alone. Most F# users admit the learning curve is a bit steep, but once you're over it, you can write better functional programs faster -- better than C# and better than Java 8. F# is also, arguably, the only commercial language for functional programming; the other options are more commonly used in academic environments.
The primary benefit its commercial bend gives F#, versus other functional languages, is its combination of easy integration and functional purity. You can access all of the .NET libraries, and also Java libraries that have been compiled to .NET -- a fairly straightforward task. But, at the same time, F# enforces functional and lambda purity in coding practices and generates more readable code. As a member of the .NET family, you can compile F# units and then use them in any of the other .NET languages, so there's no loss of .NET functionality or integrability. This is why .NET users are increasingly turning to F# for functional development; the transition is easy.
Understanding functional-friendly data structures and immutability of variables in F# is critical, and that concept can be hard to grasp for C# or Java programmers. Data structures are one of the few things that are harder in F#, which means not only that it will make a transition harder, but it might create temptation to move back to an object-oriented imperative model. It's wise to read up on functional data structures and the substitution of functions for mutable variables before you even dig deeply into F#, or you may find the framework of functional programming difficult. Simple "Hello, World" applications don't expose enough of the functional approach to be helpful. Look for samples of complex data structures, including mathematical structures.
There are no specific named classes in functional programming in Java 8 or elsewhere, and functional elements of an application should be clearly identified to prevent confusion or contamination. That means organizing your code is critical, especially in larger projects. Functional .NET programs should always be packaged and named to make the implementation language and target architecture -- F#, pure .NET -- clear. Consider reviewing the guidelines from the F# Core Engineering Group for your own projects to ensure readability of your package names. Readability of functional code is also enhanced by using consistent indenting to make function elements stand out.
While .NET functional programming has many integration advantages, many .NET developers struggle in relating functional programming to their broader applications, particularly web-based applications. Functional programs are stateless, which means they aren't as useful as interfaces to GUI processes, where it's customary for the application to retain state to support multiphase dialogs. One technique to consider in helping this process along is to think of functional elements as microservices. Microservices best practice would dictate that microservices are stateless and quite functional in nature, and functional programming in Java 8 or any other language mandates stateless components by design.
For .NET users committed to Azure, Microsoft supports functional programming as a web service, using its Functions product, and its focus is to handle event-driven elements of an application. The microservice thinking just recommended may help developers use Azure Functions to extend current logic, and even to extend Azure Functions with functional components in the data center. The benefits of Functions in event-handling are also a good primer on an important application of functional programming.
The Azure connection also demonstrates that functional programming is a natural partner to the cloud, and that may be the biggest reason why .NET users should be thinking about it. If your company believes in cloud computing, and if you still do in-house or even contract software development, then you should be taking a strong look at functional programming and the Microsoft-sanctioned tools, like F#, that support it.
Java SE 9 and Java EE
Things are *definitely* changing
Java SE 9 and Java EE 8 are here
Things are definitely changing in the Java universe. After today’s releases, there will be two Java feature releases per year (so no need to wait years until the next version is out) and Java EE is moving to the Eclipse Foundation (and changing its name). Let’s enjoy the release of Java SE 9 and Java EE 8 though.
Java SE 9
Java SE 9 has over 150 new features to offer, including a new module system and quite a few improvements which promise to bring boosted security, more scalability and better performance management.
The star of the release is, of course, the Java Platform Module System, also known as Project Jigsaw. Its goal is to help developers to reliably assemble and maintain sophisticated applications. Furthermore, developers can bundle only the parts of the JDK that are needed to run an application when deploying to the cloud so one could say that the module system also makes the JDK itself more flexible.
If you want to hear what experts think of the Java Platform Module System, here are a couple of statements:
For the full list of features, visit this page. If you want to read more about other key features such as jshell, improved Javadoc and Streams API enhancements, read this article.
If you don’t want to dive into the modular ecosystem right away, you should know that it is possible to get started on JDK 9 without modules. As Georges Saab, vice president of development for the Java Platform Group at Oracle told us a few months ago, “the class path continues to work, and this is how many developers will likely get started with JDK 9.”
SEE ALSO: Java 9 modules – JPMS basics
Moving to a 6-month release cadence
Oracle recently announced that they are planning to move to a 6-month release cadence using a time driven release model. Mark Reinhold, the Chief Architect of the Java Platform Group at Oracle, proposed that the Java SE Platform and the JDK go from “the historical feature-driven release model to a strict, time-based model with a new feature release every six months, update releases every quarter, and a long-term support release every three years.”
SEE ALSO JDK 9: Pitfalls for the unwary
Post – Java 9 plans
Oracle will also be providing OpenJDK builds under the General Public License (GPL). Furthermore, they will continue to contribute previously commercial features to OpenJDK [*cough* Java Flight Recorder *cough*] in Oracle JDK in order to make Oracle JDK and OpenJDK more aligned.
We talked with Donald Smith, Senior Director of Product Management for Java SE at Oracle about the transition between OpenJDK and Oracle JDK binaries. Read the entire interview here.
If you want to meet Donald Smith and find out more about the current status of Java EE, don’t miss his keynote at JAX London. Donald will give a quick overview of how OpenJDK plays a key role in the Java SE ecosystem, followed by details of the proposed plan and its current status.The keynote will be followed by a panel whereby the two key proposals – increased cadence and Oracle produced OpenJDK builds – will be discussed for pros and potential gotchas. Panelists include Daniel Bryant, Stephen Colebourne and Peter Lawrey.
Java EE 8
One of the reasons why the release of Java EE 8 is special has to do with its future — from now on, it will function under the stewardship of the Eclipse Foundation. Oracle, Eclipse and other community members are currently working out the details behind the technology transfer and ongoing governance and process within the Eclipse community.
Mike Lehmann, vice president of product management at Oracle said that “by open sourcing Java EE technologies to the Eclipse Foundation, we have set it up for ongoing success in the future. Oracle is committed to working with the Java EE community and the Eclipse Foundation to continue enterprise Java innovation, support and evolution.”
Oracle intends to:
Some of the key features in Java EE 8 are, HTTP/2 support in Servlet 4.0, new JSON binding API and various enhancements in JSON-P 1.1, expansion of JAX-RS to support Server-Sent Events and a new reactive client API, new security API for cloud and PaaS based applications and multiple CDI enhancements including support for asynchronous events.
For a full list of features included in Java EE 8, visit this page.
If you want to read more about the future of Java EE, don’t miss this interview series with Ivar Grimstad, Martijn Verburg, Reza Rahman and Josh Juneau.