Appeals Court Refuses to Hear Latest in $8.8 Billion Java Copyright Dispute

And so, finally, after eight long years, can this really be the end of the seemingly immortal court battle between Oracle and Google over those 37 Java APIs? The answer is ... probably not.

This week a U.S. Federal Circuit Court of Appeals declined to re-hear the case (Oracle America v. Google LLC) in which it found Google to be in violation of Oracle's copyright of those infamous APIs in its Android OS by a panel, or en blanc. Google can still appeal the ruling to the Supreme Court, but that court refused to hear an earlier appeal.

If Google appeals again and the Supremes demure again, the next step is a jury hearing to determine damages. Why take another run at the big court? Oracle is claiming $8.8 billion in damages, which is a lot of money, even for Alphabet's search giant.

In March, the appeals court ruled that Google's use the Java APIs in its Android OS was not protected under the fair use provision of U.S. copyright law. The U.S. Court of Appeals for the Federal Circuit sent the case back to a judge in San Francisco for a trial to decide how much the search engine giant will have to pay.

Oracle originally sued Google in 2010. Google's argument that its use of the Java APIs was allowed under the "fair use" provisions of the federal copyright law, and therefore did not infringe on Oracle-owned copyrights failed to persuade the court. "There is nothing fair about taking a copyrighted work verbatim and using it for the same purpose and function as the original in a competing platform," a panel of three Federal Circuit judges wrote in their March opinion.

What the appeals court found initially was that the declaration code in Oracle's API packages, which Google copied verbatim, was copyrightable. Google developed the implementation code independently, so that wasn't at issue. The court found that the Oracle code had not been merged with the functions performed by the code; that combinations of short code phrases, such as those used in the APIs, can be copyrightable; and the fact that the code serves a function does not preclude its copyrightability if, as the court put it, "the author had multiple ways to express the underlying idea" at the time of creation of the code.

Given the stakes, I think we can expect one more round.

Posted by John K. Waters on August 29, 20180 comments

Lightweight Javalin Framework Already Moving Past Milestone

The lightweight Web framework for Kotlin and Java known as Javalin reached a milestone with the release of version 2.0 last week -- and then promptly issued a point release (v2.1) this week, underscoring the growing popularity of this type of minimalist framework in general and the momentum of this project in particular.

The fledgling Javalin framework is simple, lightweight, and flexible. It supports WebSockets, HTTP2, and async requests, and goes a long way toward making life easier for a range of developers. It's primary claim to fame, of course, is its "first class" interoperability between Kotlin and Java.

"Javalin is more library than framework," the Javalin team wrote in a blog post, "you don't need to extend anything, there are no @Annotations, no reflection, no other magic; just code."

Version 1.0 of the Javalin framework was released in November 2017. It actually started life as a fork of the Spark Framework, another simple Java/Kotlin Web framework, but the project evolved quickly into a "ground-up rewrite" influenced by express.js, an unopinionated, minimalist Web framework for Node.js. The framework runs on Eclipse Jetty, one of the most used and stable Web servers on the JVM.

The operative word for all of these frameworks is "lightweight." They were inspired, their contributors say, by Sinatra, a modern micro Web framework written in Ruby and considered the grandfather of these offerings. And the focus is on getting things done quickly and with a small amount of code.

A lot has changed since the last release -- more than 180 files, according to the Javalin team. Those changes included approximately 5,000 additions, 5,500 deletions, "which is more or less the entire code base," they said.

The popularity of Kotlin among Java developers has been growing steadily since JetBrains created and then open-sourced the statically typed programming language in 2011. The language compiles to both JVM byte code and JavaScript. JetBrains, the Prague-based maker of the venerable code-centric Java IDE IntelliJ IDEA, has claimed that Kotlin is more stable at runtime than Java, because it can statically check weak points and supports things like variable type interface, closures, extension functions, and mix-ins. It's also less verbose than Java, which means devs can write less code with a more readable syntax. During a memorable keynote demo at the 2017 Google I/O conference, Google's Android team showed an example of how Kotlin could accomplish in one line of code the same thing that required 87 lines of Java code.

The Javalin project code files and details are available on GitHub. A complete list of the changes between the 1.0 and 2.0 release can be found here.

Posted by John K. Waters on August 28, 20180 comments

The 16th Annual Duke's Choice Award Nominations Are In!

The nominations for the 16th annual Duke's Choice Awards closed this week. The winners will be announced at The Developer Conference Formerly Known as JavaOne in October. (Okay, it's Oracle Code One. I'll get used to it eventually.)

Duke, of course, is the official Java mascot, a red-nosed, triangular thingamajig that cartwheeled across our screens to oo's and ah's back in the day, when Java was the Green Project. He (I'm assuming here) was created by graphic artists, Joe Palrang, who would later work on animated movies, including "Shrek," "Over the Hedge" and "Flushed Away," and he/she/it was open sourced along with Java SE and Java ME in 2006.

The awards named for the little guy "celebrate extreme innovation using Java technology," Oracle says on its Web site. Big O is running the event, of course, but the nominations come from the community. Nominations from just about anyone are accepted, including Oracle employees and ambitious self-promoters. You can nominate a project, person, product, service, or "any program related to Java innovation."

The judging levels the field, Oracle says: "The primary judging criterion for this prestigious award is innovation, putting small developer shops and individual developers on an equal footing with global giants."

Nine winners were selected last year in what I think was meant to be a nod to Java 9. All nine received full conference passes JavaOne, winner badges, and a Duke statue, inclusion in Oracle corporate social media programs, and perhaps most important, community recognition as elite members of the Java ecosystem.

While we wait for the results to be announced at Oracle Code One (See? I just needed five paragraphs to get there.) I think it worth re-acknowledging last year's winners. From a lightweight Docker interface to a tool designed to tackle the extremely complex challenges associated with optimal interplanetary trajectory design, it's an impressive lineup:

  1. Rapid Dashboard (Hakan Ozler)
    Lightweight Docker developer interface for Docker remote API.
  2. The Java Terminal Project (Rahman Usta)
    Provides the ability to run a fully featured terminal emulator on Linux, Mac and Windows. Supports Cloud and Web apps.
  3. Robo4J (Marcus Hirt & Miroslav Wengner)
    A framework to quickly start building and running robots and IoT devices.
  4. jHipster (Matt Raible)
    A development platform to develop and deploy Spring Boot + Angular Web applications and Spring microservices.
  5. On Board (Bert Ertman)
    Collects real-time sensor data from marine vessels to provide captains and crew performance info.
  6. U en Linea - Catholic University Luis Amigo (Hilmer Chona)
    Heart of the University information system started in 2010, has student developer input, and runs on Oracle VM server cluster with WebLogic and Oracle DB
  7. ControlsFX (Jonathan Giles)
    Library for developers of JavaFX applications with huge download stats.
  8. Deep Space Trajectory Explorer (Sean Phillips)
    Created to tackle the challenges of interplanetary trajectory design.
  9. Latin America Virtual JUG (Cesar Hernandez) Collaboration among Spanish speaking JUGs in Mexico, Colombia, Peru, Guatemala and Panama. Together, delivered a full day of Spanish content on Cloud Day Mexico City.

Posted by John K. Waters on August 14, 20180 comments

Apache NetBeans 9.0 Approaching Final Approval

The Apache Software Foundation (ASF) has been working hard on its first release of the NetBeans IDE since Oracle contributed the popular software development environment to the ASF in October 2016. The community has finally given a thumbs up to Apache NetBeans 9.0. All that's left is the tabulation of a final vote by the project management committee (PMC), the compilation of the results of a community survey, and the final vote by the incubator managers.

The ASF has gathered the final vote by the Podling Project Management Committee (PPMC) -- essentially, a group of community members charged with helping a nascent project, called a "podling," learn how to govern itself. According to the ASF, a PPMC works like a regular PMC, but reports to the Incubator PMC instead of the ASF Board. Initially, this group includes the podling's mentors and initial committers. The PPMC is directly responsible for the oversight of the podling, and it also decides who to add as a PPMC member. (Click here to read the related Apache NetBeans dev mail thread.)

The ASF is no longer accepting responses to the Apache NetBeans 9.0 Community Acceptance Survey, which focused on functionality. The results will be available, soon.

The ASF was set to begin the Apache NetBeans IPMC voting process on July 22, which enables members of the Apache Incubator to approve the release. It's all tentative at this point, but if all goes as planned, Apache NetBeans 9.0 will be released during the first weeks of August.

This first Apache NetBeans release is focused specifically on Java SE tooling. According to Geertjan Wielenga, Oracle product manager and developer advocate for open source projects, that's because NetBeans is so large; it will likely be the largest project under the aegis of the ASF once everything has been donated. This is a 20-plus-year-old project, he noted in a blog post, and it provides support for an enormous range of technologies. Because so many files needed to be audited before they could be donated to Apache, he said, the decision was made to donate NetBeans in pieces.

"And since NetBeans is modular," he explained, "doing an incremental donation was not difficult to architect. The first donation focused specifically on the underlying core, i.e., the NetBeans Platform (e.g., the module system, window system, menubar, etc.) and, to enable the result of the first donation to be usable for general users and not just NetBeans Platform developers, the various Java SE features were included too, e.g., Java project templates, Java editor, and new Java features such as support for Jigsaw, JLink, and JShell."

That first donation effectively constitutes Apache NetBeans 9.0. The second donation has been completed, which means Oracle has audited and donated all the modules for features providing support for JavaScript, PHP, Groovy, and Java EE. Those features are on a separate branch in the Apache NetBeans Git repo, and they will be integrated sometime after the 9.0 release. The next set of modules being audited prior to donation are related to C/C++, he said.

NetBeans continues to be a popular Java IDE (1.5 million active users, according to the community), but it has grown beyond Java to support C/C++, Groovy, PHP, JavaScript, and the HTML5 and CSS Web development standards.

Posted by John K. Waters on July 25, 20180 comments

Milinkovich on Eclipse's New Quarterly Release Train, the LSP and Progress on Jakarta

The annual Eclipse Release Train chugged out of the station right on time again this year, with 85 projects in tow, but with this release, the Eclipse Foundation threw a switch (pardon the tortured metaphor) that put the train on a much faster track. The new quarterly rolling release cadence, announced today, is more of a rebranding of a process started last year with the quarterly point releases of the Oxygen Release Train.

The Foundation's executive director, Mike Milinkovich, characterized the change as "the end of an era." And it has been a remarkable run: 13 years without a miss. That's a tough act to follow, and yet the Foundation actually raised the bar for itself with the new quarterly coordinated release schedule. And they did it while taking on responsibility for enterprise Java.

I couldn't help wondering if Milinkovich gets any sleep, but he reminded me that he's not in this alone.

"Because we do ship something that looks a lot like a product, and we keep to something that looks like a release schedule, people forget sometimes that we're not a vendor," he told me. "But I remind you every year that I don't get to tell anybody to do anything. The success of the release train speaks to the possibility within open source communities of doing things in a disciplined and predictable fashion. There's nothing about open source that prevents good software engineering practices, even product management practices."

He also reminded me that there are many projects in every release train not backed by corporations, but supported solely by individuals. What draws those individuals to this model, he said, is its predictable nature and the widespread adoption it promises. In other words, it gets their technology into the hands of millions of developers.

"That's catnip for developers," he said. "They know that this thing they're building is going to be used by millions of people -- which is totally understandable. The last thing you want to do is build something that nobody uses."

The faster release cadence is a huge change and a response to new, industry-wide expectations for faster releases. Or, as the Foundation put it in a release, it "demonstrates a commitment to keeping pace with evolving developer and commercial needs." That attention to this evolution can also be seen in the new native Eclipse IDE support for the Rust language and C# through Language Server based plugins. The Language Server Protocol (LSP) ecosystem delivers editing support for popular and emerging programming languages.

"I remember going to a JavaOne conference 20 years ago and hearing people say that Java was the last programming language we would ever need," Milinkovich said. "I didn't believe it then, and I think it's pretty obvious that no one believes that now. We live in a polyglot world. Lots of developers have to deal with multiple languages and multiple stacks. The ability to quickly add support for new languages in this way I think is very powerful and something that will serve the Eclipse community for many years to come."

Meanwhile, the Foundation continues its work on Jakarta EE, Milinkovich said. All of the projects have been created and provisioned, and code is going into them. He's expecting to see GlassFish builds in a few weeks available for download. Soon after, he expects to see a certified release as Java EE 8 compatible, which he sees as a major milestone.

"The hard work is still ahead," he said. "We're creating a specification organization, so there are lot of things we have to deal with that developers don't care about, but corporate lawyers love -- everything from patents to trademarks. Still a lot of heavy lifting to be done before Jakarta EE is truly up and running as the full successor to Java EE."

"Everything is going extremely well," he added, "in that we're having some tough conversations about difficult subjects, and everyone is being constructive and friendly. Things always take longer than you expect, but I'm optimistic that the process will continue ... and we'll get there soon."

Posted by John K. Waters on June 27, 20180 comments

Waratek's Giannakidis: Removing Serialization from Java Is Not the End of the Story

Last month, Oracle's chief architect, Mark Reinhold, said during a conference Q&A that one of Oracle's long-term goals is to change the way Java handles object serialization. In fact, he called the decision to adopt the current serialization feature a "horrible mistake," and a virtually endless source of security vulnerabilities.

Java object serialization is the process of converting an object into a stream of bytes for transport and storage. Oracle is currently planning to develop a plugin mechanism that will allow developers to choose a serialization format, such as XML, JSON, YAML. They'll also be able to choose the existing native serialization. Oracle says it is also developing a new, safe serialization format based on a new language feature called data classes, which is part of the project Amber.

Removing serialization is one of the goals of Project Amber, an OpenJDK project that aims to "explore and incubate smaller, productivity-oriented Java language features that have been accepted as candidate JEPs under the OpenJDK JEP process," the project page explains, including lambda leftovers, pattern matching, local-variable syntax for lambda parameters, switch expressions, and raw string literals. Announced last year, the project is being led by Oracle's rockstar Java architect Brian Goetz. He discusses his ideas around "the possible direction of data classes in a blog post.

Apostolos Giannakidis, security analyst at Waratek, a Dublin-based app security tools provider with a special focus on Java, is one of my go-to Java security experts. He does work for a security products vendor, but his insights are always spot on. He shared his thoughts on these long-time-coming changes in a recent blog post, with the subtitle "Oracle has declared an end to Java's serialization approach, but that's not the end of the story."

"There is little doubt that serialization issues plague Java and that addressing the underlying causes will benefit the Java community," Giannakidis wrote. "But how long will it take to bring a new approach to the market, and will simply replacing the old serialization mechanism with a new approach end the issue?"

Among his concerns: removing the existing serialization mechanism will take at least a couple of years. "The current approach to serialization is two decades old and is the foundation of hundreds of Java SE components," he wrote. "Even when an alternative approach becomes available, Oracle will likely keep native serialization as an option just to maintain backwards compatibility for a few more years."

He also worries that enterprise middleware, servers, and higher-level protocols (such as RMI, JMX, JMS, etc.), which depend on Java's native serialization, are going to be very difficult to change. Software vendors might need years to switch to any alternative technology. And backwards compatibility will be a big issue.

"Even if all the above issues are resolved, deserialization vulnerabilities are not going away," he wrote. "Java's native serialization is not the only flawed serialization technology. XML and JSON deserialization vulnerabilities exist and are real threats to enterprises. In the recent months, attackers exploited these vulnerabilities (such as CVE-2017-9805) to infect with crypto-mining malware their targets."

Deserialization reverses the process when the data is received. It can also be used to reconstruct an object graph from a stream.

While Oracle gets its arms around its serialization-removal plan, legacy servers and applications will continue to be vulnerable, Giannakidis warned. "It is difficult now for most organizations to keep pace with Java updates," he wrote. "Oracle's co-CEO Mark Hurd recently acknowledged that Java users typically run months to years behind in patching. Upgrading versions or rewriting apps takes even longer, if practical.

He also warned that non-Java shops should be worried about deserialization issues, because Java isn't the only platform affected by it. .NET, Ruby, PHP, Python, and others are all subject to deserialization vulnerabilities.

Posted by John K. Waters on June 11, 20180 comments

Enterprise Java in the Blogosphere

So much has happened in the enterprise Java space over the past few months that it kind of boggles the mind. Fortunately, the rockstars, gurus and industry watchers have been busily sorting out the whats and wherefores of this epic transformation in the blogosphere. (You thought it was just me, right?) Seems like a good time to pass along a bit of that wisdom with some recommended reading.

Mike Milinkovich, executive director of the Eclipse Foundation, should definitely go first here, because his was the calm and experienced voice in the middle of the early dear-god-don't-call-it-EE4J storm. His writing on the Eclipse Foundation's "Life at Eclipse" blog provided the urgently needed clarity of facts as the process of moving Java EE from Oracle to his organization stirred a blinding cloud of rumors and fears. His blog was also often interactive, a place where the new regime reached out to the community for its opinions and concerns, at times literally surveying the people most directly affected by the changes. One of my fav posts: "On Complexity and Good Intentions." (Great title, too.)

Reza Rahman, long-time consultant, former Oracle Java developer evangelist and co-founder of the Java EE Guardians, is another must-read enterprise Java blogger in general, but he's doing something new that should get some extra attention: he's posting successful Jakarta EE adoption stories. His latest is from a young developer in the Czech Republic working on medical applications, who shares his experience with both Spring and Java EE applications. He also points to a long list of adoption stories curated on the Java EE Guardians Web site.

Mark Little, vice president, software engineering, at Red Hat, is another must-read blogger. On the subject of the open sourcing of Jakarta EE, he holds forth in a brief, but heartfelt post entitled "Jakarta EE is Officially Out," by which he meant "available." Red Hat has been among the leaders of this transition, and Little is often right out there at the forefront.

Tomitribe Founder and CEO David Blevins' post "Java EE to Jakarta EE" was another how-we-got-here-and-where-are-we-going piece about the rebranding. I reached out to Blevins early in this process, but he and his colleague elected to stay quiet until the ball was well and truly rolling. This post offers some insights into the renaming process early on, and makes the case for Jakarta EE. It's done deal, I know, but it's good to see some of thinking behind the changes.

I must mention another Tomitriber here: Richard Monson-Haefel, author, analyst, veteran Java developer, who's March 30 post, "I (heart icon) Jakarta EE" just made me feel good about the future of enterprise Java. It's the story of his journey from early enthusiast to disillusioned apostate and back again. Just a well written story that got me interested in his other posts. It'll do the same for you. (I also loved "Jakarta EE Into the Fourth Epoch." The guy is a good writer.)

In February, Lightbend senior developer James Roper posted a rich piece on the company's Tech Hub blog site called "What can Reactive Streams offer Jakarta EE?" In it, he shares his ideas on this topic with lots of detail, starting with a high-level use case. (Lightbend, of course, is the company behind Scala.)

Nice post by IBM's Ian Robinson on the developerWorks blog: "Jakarta EE – The new home for enterprise Java." Big Blue has a real stake in the Java space, and those with a long memory will recall that it was the original home of the Eclipse Project, which it open sourced way back in 2001. Plus, you gotta love a blogger who quotes an obscure Queen lyric.

Ivar Grimstad posted a nice clarifying piece called "The Relationship Between Jakarta EE, EE4J and Java EE." Grimstad's posts are informative and to the point, and this one is no exception. This particular post was listed in the FAQ section of the Jakarta EE Web site at launch.

Software evangelist David Delabassee published a nice, short piece in April entitled "The Road to Jakarta EE" on Oracle's official Aquarium blog, in which he offers a little roadmap, acknowledges his colleagues' efforts and shares a few insider observations on the process of moving Java EE to Eclipse.

Finally, you don't get much more nuts-and-bolts than Java rockstar and consultant Adam Bien's blog. Code snippets, on-the-ground examples and advice, video clips and tons of links; it's just a blog you should be reading. (But you knew that.)

This is just a handful. I'm hoping you'll let me know which ones I should have included, but didn't. (In the comments section or on Twitter @johnkwaters.) This is going to be a long conversation, and I, for one, think the more voices we hear from, the better.

Posted by John K. Waters on May 30, 20180 comments

Future of Jakarta Is in the Cloud, Not with the JCP: One-on-One with Mike Milinkovich

The Eclipse Foundation today unveiled its game plan for Jakarta EE, published the results of a community survey on the future of that technology platform, and explained the open source governance model it will use to manage its development going forward.

It almost goes without saying that taking over the responsibility for the development of enterprise Java is an enormous undertaking. But I didn't realize until I spoke with the Foundation's executive director, Mike Milinkovich, that his organization would also be taking over the responsibilities of the Java Community Process (JCP), guiding and approving the Jakarta EE technical specifications going forward.

I talked with Milinkovich about these changes last week.

Specification approval is fresh territory for the Eclipse Foundation. How are you dealing with this new responsibility?
This is the first time the Eclipse Foundation has had to put together a specification process. We don't even know what we're going to call it yet. We do know that new specification process is going to be different in many ways from the JCP's. The new versions of the JCP process have been open and transparent. However, the fact that the JCP was owned and operated by Oracle, and to participate you had to sign the Oracle contributor agreement and give the company joint ownership of your contributions were perceived as barriers to entry. Partners in partners in industry, individual developers, and everybody in between no longer accept this as state of the art, in terms of how you move an important technology platform forward.

How will your approach be different?
What we are going to be striving for in this new spec process is openness and transparency, of course, but also to provide a level playing field, in terms of the intellectual property flows, and absolutely state-of-the-art best practices for developing specifications, with the expectations of open-source and commercial implementations resulting from those specs."

Just to be clear, the Eclipse Jakarta EE Working Group is where the new specification process is going to be managed entirely, and the JCP is out of the picture. Right?
Right. The JCP is going to continue to exist, of course, but it will be focused entirely on the Java language platform, the JDK, the JRE, that level of the Java technology. The Eclipse Foundation and its members and the Jakarta EE Working Group will define the future evolution of cloud-native Java.

"Cloud-native" is already something of a mantra for Jakarta EE, largely because of the survey results, but you guys were already thinking along these lines, weren't you?
Ultimately, what we are trying to do here is to take a technology that is approaching its 20th birthday and give it a whole new life. I have to say, when I talk to people, whether it's in person or through the mailing list, there is still an enormous amount of energy and passion in the Java EE community. If we can tap into that and give developers the tools they need on this platform to be successful in this new cloud-native, microservices-centric kind of world, they're going to love what's coming out of the Jakarta EE projects. This is an opportunity for this community to get a whole second generation of technology and momentum, and that's really what we are working very, very hard toward.

What happens to the millions of people who are still using Java EE?
People using older versions of Java EE will continue to get support. This is not the end of Java EE. Java EE 8 just shipped. The existing vendors -- Oracle, IBM, Red Hat, Tomitribe, and others -- are going to be supporting Java EE 8 and previous versions under the Java EE brand for many years to come.

How involved are the big vendors with this new process?
One of the things that's different about the way we set up this working group, which I think is very important, is that we have explicitly carved out a role here for enterprises that are the big adopters of the technology. The big vendors that are contributing lots of resources to this are going to be on the steering committee to help guide the project.

Why are you going after enterprise adopters?
What we really want here is to get the big consumers of this technology actively engaged with this community and its projects and its governance. Even beyond Jakarta, I believe that this the next big wave in open source, to get the big consumers of the technology to move from being passive consumers to being actively involved with, and helping to sustain, the technologies that they rely on. That's something that we are going to working on, very hard, over the next year, to get the message out to enterprises that, if you are relying on this tech, come join in and become part of this community. Don't just sit there and download the releases when they're done. Open source gives you the opportunity to be a much more active participant than the historical vendor/customer relationship.

You've said before that "Jakarta" isn't really a rebranding of Java EE. Could you explain that statement?
There was a lot of controversy around Oracle's refusal to allow the use of "Java EE," but the truth is, keeping that brand would have been a bad idea. The Java EE brand, I believe, is cemented in developers' minds to the on-premise, monolithic app server model. But Jakarta EE is about cloud-native and microservices. This as an opportunity for us to use that new name and new brand to bring new value to developers. There are developers out there who would probably never take the time to try a new version of Java EE. But there's a good chance that they'll take the time to try a new version of Jakarta EE. And I think that's a good opportunity for all of us.

What's the status of "EE4J"?
Everyone was calling Java EE at Eclipse EE4J for a while because we had to call it something during the transition. Now, "EE4J" is simply an Eclipse Foundation organizational artifact. It's not the name of the technology or its brand. It refers only to the top-level project that things like Eclipse Glassfish and Eclipse Jersey fall under. Those projects live under the management of the EE4J Project Management Committee.

Does the fact that Java EE, which is one of the world's most widely used technology platforms, found its way to open source say anything the status of open source or the evolution of this kind of software?
I believe it's indicative of a trend. When you have a technology that has become an industry standard, as opposed to a company product, bringing it into an open-source organization like the Eclipse Foundation, the Apache Software Foundation, or the Linux Foundation is the best way to ensure that the entire ecosystem will trust your technology. It's what you must do if you want to inspire global adoption of your technology. This is an incredible endorsement of our respective institutions. And it's important that there is more than one, so we people have a choice.

Jakarta EE is another example of that trend, and a pretty big one. If we get this right -- and we will -- it's going to be one of the most amazing technology journeys to watch in quite a few years. We are extremely optimistic that we are going to be able to bring this platform forward with the support of a passionate and engaged community. And it's going to be a lot of fun.

Posted by John K. Waters on April 24, 20180 comments

Waratek Patch for Java and .NET Demo at RSA

The annual RSA Conference gets under way next week in San Francisco, which means the Moscone Center will be packed with infosec mavens from "the frontlines of the cybersecurity landscape." (So cool.)

The speaker list includes Kirstjen Nielsen, Secretary of the Department of Homeland Security, Christopher D. Young, CEO at McAfee, and RSA President Rohit Ghai. And topping my list of presentations: "The Five Most Dangerous New Attack Techniques, and What's Coming Next."

Expect tons of vendor announcements at this year's show, of course. One that I'm looking forward to for Java jocks comes from Waratek, the Dublin-based app security tools provider with a special focus on Java. The company announced this week that it will demo its new Patch tool for Java and .NET applications (booth #4341 in the North Hall).

Waratek Patch applies virtual patches for long-term and newly discovered vulnerabilities. It's a lightweight agent designed to allow security and development teams to create and apply custom patches based on scanning tools. Regular updates from Oracle, Microsoft, Apache, and other software developers can also be instantly deployed, the company said in a statement, using functional-equivalent "virtual" patches that operate just like a physical binary without delay and the risk of breaking an application.

In its announcement, the company used recent examples to underscore why application security should be a front burner issue in every organization:

"Cybersecurity breaches in the month of April are stark reminders of the need for organizations to secure vulnerabilities in their networks. Under Armour, Panera Bread, Delta Air Lines, retailers Best Buy, Sears, Saks Fifth Avenue, Saks Off Fifth, and Lord & Taylor stores are among companies reporting successful cyberattacks resulting in the loss of valuable customer data. The scale of these security breaches highlights the importance of detecting software flaws and patching vulnerable software before attackers have the chance to take advantage of a flaw."

BTW: This year's RSA includes a new "on demand" feature for those who can't make it, physically, to the City by the Bay. Lots of conference content included here, including my fav: The Cryptographer's Panel.

Posted by John K. Waters on April 11, 20180 comments