Credits: Sdtimes

Credits: Sdtimes


Society often has a misconception on what AI really is and what it can do thanks to movies like “The Terminator” and “Wall-E.” Facebook wants to change that perception with a series of educational videos designed to make artificial intelligence easier to understand.

“AI is going to bring major shifts in society through developments in self-driving cars, medical image analysis, better medical diagnosis, and personalized medicine,” wrote Facebook AI researchers Yann LeCun and Joaquin Quiñonero Candela in a blog post. “And it will also be the backbone of many of the most innovative apps and services of tomorrow. But for many it remains mysterious.”

According to the company, AI falls into three types of learning: reinforcement learning, supervised learning, and predictive learning.

PHP releases 7.1.0
PHP has released the first point version of the 7.x series.

New features include nullable types, which is common in programming languages that allow a variable to be of some type or null. Other features include void return type, iterable pseudo-type, class constant visibility modifiers, and other changes that can be reviewed here.

Besides this point release, PHP also announced its 2017 conference is now open for PHP developers.

Software AG acquires Zementis
Software AG has acquired deep learning and artificial intelligence company Zementis so it can move forward with the next generation of Internet of Things applications, like self-driving cars and digital assistants.

Software AG already embedded Zementis’ ADAPA technology into its Digital Business Platform, and together, the combination of technologies will deliver business and technical insights that will help customers determine behavior, security risks, and sensor information from IoT devices, according to an announcement from Software AG.

“The impact of the Internet of Things on industry, business and society will dwarf anything we have experienced through technology so far,” said Software AG CEO Karl-Heinz Streibich. “This is now widely acknowledged by industry, as is the unique business insights that can be provided by combining predictive analytics, machine learning and streaming analytics.”

Credits: Escapistmagazine

Credits: Escapistmagazine

When it comes to programming, learning by doing is the way to go. Learning by recreating one of your favorite games? Even better. Get the Java Game Development course and create a Flappy Bird clone for $19 at Escapist Deals.

The course is packed with 29 lectures that take you through every step of creating a game like Flappy Bird. You’ll learn important Java tools and core game development concepts along the way, ensuring you come out of the course with both a finished project in your portfolio and a great programming foundation that’ll help you get your first job as a coder.

Credits: Sitepoint

Credits: Sitepoint


Java is over twenty years old and is consistently rated as one of the most popular programming language on the planet. Part of what makes Java so appealing to developers is the way that features evolve in a controlled way that rarely has any impact on backwards compatibility. The way Java evolves has had a somewhat varied history, especially with respect to open source. In this article we’ll look at how the Java platform is standardised whilst maintaining community involvement through the Java Community Process (JCP). We’ll also see some of the challenges that process has faced and still faces today.

Before the JCP

After its launch, Java rapidly gained popularity and numerous corporations, both big and small, wanted to be part of this exciting new software platform. In the early days, IBM quickly got involved through Taligent – a joint venture between IBM and Apple, which started out developing an object-oriented application framework. Taligent also had strengths in internationalisation and contributed a number of classes to JDK 1.1 (like the java.text package and the java.util.Calendar class).

Microsoft became a Java licensee as well, integrating it into early versions of Internet Explorer. Microsoft’s implementation caused a lot of trouble, resulting in a long and protracted lawsuit over how Microsoft broke the terms of their license agreement. This was ultimately settled in Sun’s favour but was essentially what prompted the development of C#.

Around 1997 there was a lot of pressure on Sun Microsystems to hand over the standardisation of Java to a well know international standards body such as ANSI or the ECMA. Sun was not keen to do this for two reasons. Primarily, it would give control of the Java platform to other people and Sun realised the value of Java to them, certainly in terms of marketing if not in pure revenue.

The second reason was more about how quickly Java could evolve over time. Standardisation processes can be classified on a spectrum where one end is a single company with total control and the other is a completely open process where all involved parties have an equal say. Each of these has strengths, but also weaknesses. If Sun continued to control the development of Java alone, developers would simply have to accept whatever Sun’s product management deemed to be the best features. If Sun handed Java over to someone like ANSI the speed of development would be impacted. Open, international standards bodies are notoriously slow in developing and ratifying standards (ANSI has only managed to produce three revisions of the C standard in the last 26 years!)

The Java Community Process

Sun’s management decided that the best way to develop the specifications for Java was to create a new standards body whose processes would be somewhere between the two ends of the spectrum. Having released an initial proposal in October, Sun officially launched the Java Community Process (JCP) on December 8th, 1998, which was the same day it released JDK 1.2. It also took this opportunity to rebrand Java as Java 2 and introduced the concept of different ”editions”, specifically:

  • Java 2 Micro Edition (J2ME) for mobile and embedded devices
  • Java 2 Standard Edition (J2SE) covering the language, core libraries and JVM
  • Java 2 Enterprise Edition (J2EE) for enterprise applications using components like servlets and Enterprise Java Beans (EJBs) in an application server container (who says microservices are new?)

The JCP’s Structure

The JCP would be made up of parties interested in contributing ideas for how Java could be developed. Initially, membership was restricted only to corporations but that was later changed to include Java User Groups, academics and even individuals.

Fortunately, Sun realised the key word in the name of the JCP was Community.

The original structure of the JCP had two Executive Committees (EC), whose role was to approve the passage of specifications through key points of the process. One EC was responsible for J2ME and another for J2SE and J2EE. In August 2012 these were merged into a single EC for all Java standardisation activities.

Today, under JCP rules Version 2.10 the EC is formed of the following:

  • 16 ratified seats
  • 6 elected seats
  • 2 associate seats
  • 1 permanent seat for Oracle America

Members serve 2-year terms that are staggered so that 12 of the 24 seats are normally up for ratification or election each year. The latest version of the JCP charter also removed the requirement for membership fees. The current goal is clearly to increase membership and therefore participation from the community.

Changing Java through the JCP

Any full member of the Java Community Process can submit a Java Specification Request (JSR), which consists of a variety of information about the proposed specification including a description of what it will standardise, estimated dates for development and why it is required. The EC votes on the JSR and, if accepted, the process of developing the standard begins.

To do this an Expert Group (EG) is formed from full JCP members or member representatives who are interested in helping to develop the specification. The specification lead (typically the person who submitted the JSR, but this can change over time) decides who to accept for the EG. Once the EG has created the specification it is published for public review before the JCP membership votes for its approval.

The deliverables of a JSR consist of three parts and make up the “golden triangle” of the JCP:

  1. The formal specification
  2. A Reference Implementation (RI) of the specification
  3. A Test Compatibility Kit (TCK)

The diagram below shows the relationship of these three parts.


Initially, the JCP saw a storm of activity with many JSRs being filed, expert groups created and specifications defined. At the time of writing, there are 380 JSRs listed on the JCP website with a further 27 maintenance JSRs covering existing specifications.

Another mechanism also exists for accepting and tracking changes to the Java platform: that of JDK Enhancement Proposals (JEPs). Sun finally released the source code of it’s Java Development Kit (JDK) in 2006 under an open source license and started the OpenJDK project to manage this. The Java SE specification defined through the JCP only covers the Java language, virtual machine and class libraries. JEPs cover any modification to the JDK, which may lead to changes being passed into relevant JSRs. As we will see later, these have recently become a topic of some debate.

The Java Specification Participation Agreement

Another important part of the JCP, which I have not mentioned so far, is the Java Specification Participation Agreement (JSPA, pdf). This is significant because it covers the intellectual property (IP) rights associated with JSR specifications. Initially, the JCP did not provide any way for independent implementations of JSRs so there was no ability to produce open source versions.

At JavaOne in 2002, the big announcement was that the Apache Software Foundation (ASF) was joining the Java SE/EE EC. It was also announced that all current and future JSRs led by Sun would be made available under a license that allowed for open source implementations.

Section 5 of the new JSPA covered outbound IP and ensured that the specification lead granted a perpetual, royalty-free, irrevocable license for copyrights and patents covering the specification to anyone who wished to create an independent implementation of the specification. In order to qualify for this, the implementation would have to fully implement the specification, not modify, subset or superset the specification and pass the TCK.

Harmony Strikes the Wrong Chord

For some years the JCP ran smoothly with a wide variety of JSRs submitted, specifications written and both commercial and open source implementations created.

On September 30th, 2004 Java 2 SE 5.0 was launched. This included significant changes to the Java language syntax and also changed the numbering scheme of Java once again. To indicate the level of change to the platform the release number was moved forward to 5.0. Through the JCP, the release contents were specified in JSR 176, which was an “umbrella” JSR. This specification defined contents that also included elements specified by other JSRs, for example generic types from JSR 14, annotations from JSR 175, etc.

Then things got more complicated.

Enter Project Harmony

In May of the following year, a new incubator project was created by the ASF whose goal was “architecting and implementing J2SE 5”. This was known as Project Harmony. For some time prior to this announcement proponents of Free and Open Source Software (FOSS) had wanted the source code of Java to be freely available with an open source license. Sun had resisted this call for a variety of reasons; not least of which was the sheer amount of work that due diligence would require to enable them to release the source code under an open source license, but also, as we’ll see, because of how Sun made money from Java.

Since Java’s specifications were freely available from the JCP, in theory, it would be possible to produce a “clean room” implementation that could be distributed free of Sun’s binary licensing terms. The most significant of these was the Field-of-Use (FoU) restriction. The FoU essentially said that Java could be used freely (i.e. without paying Sun a licensing fee) as long as it was used on “General Purpose Desktop Computers and Servers”.

Sun Resists

At this time, the only place that Sun made any revenue directly from Java was licensing Java Card (a tiny subset of Java that ran in only a few kilobytes of RAM) and Java 2 ME, which was used by mobile phone manufacturers. Sun wanted to protect this (not insignificant) revenue stream.

Work on an open source version of Java had started back in 1998 in the form of the GNU Classpath project, but that had only focused on the standard class libraries of Java, not the virtual machine. Project Harmony intended to produce a complete open-source Java runtime environment.

Unfortunately, this is where the problems started. In order for an implementation of JSR 176 to be granted free use of all necessary IP and for it to be called Java that implementation must pass all the tests in the TCK. In August 2006 the ASF approached Sun to gain access to the TCK for JSR 176 (to make things a little more confusing the TCK, in this case, is also referred to as the Java Compatibility Kit (JCK)). Despite the announcements made at JavaOne in 2002, Sun would only provide the TCK/JCK to Apache under certain licensing restrictions. These restrictions meant that any implementation tested would still be constrained by a FoU very similar to Sun’s binary distribution.


Apache clearly felt that this was in contravention of the JSPA and wrote an open letter to Sun Microsystems on April 10th, 2007 essentially demanding that Sun honour the terms of the JSPA and provide them with the TCK under an appropriate license. Sun refused to do this.

The impasse was finally resolved after Oracle acquired Sun Microsystems and put the proposed Java SE 7 JSR to a vote of the Java SE/EE EC. This was effectively a vote on whether the licensing terms of the TCK for Java SE would change to allow the ASF access the way they wanted. However, despite the objections of several members of the EC, the vote was passed paving the way for the JCP to return to developing standards as normal.

Tim Peierls and Doug Lea, both individual members of the SE/EE EC resigned in protest. The ASF tried one more time to get Oracle to honour the commitments of the JSPA but eventually resigned from the JCP SE/EE EC in December 2010.


State of Affairs

Since the ASF left the JCP over forty JSRs have been proposed covering all aspects of Java. Does this indicate that all is well now with the JCP? In some ways, yes, but it still has its issues.

Java ME

There are only two JSRs relevant to Java ME from the last few years covering the Connected Limited Device Configuration (CLDC) release 8 and the Java ME embedded profile. Now that mobile phones have moved away from Java ME and many embedded devices are easily powerful enough to run a full Java SE implementation it’s difficult to see where Java ME will go in the future.

From Java SE 8 on, the plan from Oracle was to have Java ME releases in step with Java SE. Right now, it seems unlikely that there will be a Java ME 9 next year.

Java SE

Component JSRs have been submitted for various core platform features. The most significant recently was the Java Platform Module System (Project Jigsaw, JSR 376) to be included in Java SE 9 (JSR 379).

The management of Oracle’s Java Engineering Group recently addressed the JCP EC on the subject of the JSRs for Java SE. The issue they have is that software development has changed a lot in the last twenty years and a more agile approach to the development of the core Java platform is required. JSRs use a structured process for development that does not lend itself well to this methodology.

The JDK Enhancement Proposals (JEPs) were introduced to the OpenJDK project to address this need. JEPs cover smaller pieces of work than a full JSR and can be included or excluded from a JDK release quickly and easily (JDK 9 is already demonstrating this).

Despite the use of JEPs there will continue to be JSRs for Java SE, but they will collect all of the changes when a release is ready to ship, rather than defining these at the start of the development process. This is good because it ensures the IP for Java SE is available under the same terms as before. However, there are some concerns from people wanting to do commercial “clean room” implementations of the JDK, as the only specification reference will be the OpenJDK project until the Java SE JSR is eventually published.

Java EE

Numerous JSRs had been submitted for the various aspects of Java EE such as EJBs, Servlets, Web Services, MVC, etc. all intended to be part of Java EE 8. Recently, though, there was considerable concern in the Java community that most of these JSRs had no activity associated with them and that Oracle was no longer actively developing Java EE. Recent announcements at this year’s JavaOne have promised to put Java EE 8 and 9 back on track so expect to see a lot more progress on these JSRs in the near future.

In the End, It’s All about Community

The JCP certainly faces challenges moving forward. To ensure that standards remain open it is important that membership of the JCP continues to grow. Recent changes to the JCP membership agreement are a clear step in the right direction for this.

Most recently the JCP had elections for the membership of the EC. Since the election was the first to be held under the new version 2.10 rules all seats were up for re-election. The EC is now made up of sixteen ratified, six elected and two associate seats as well as one permanent seat for Oracle America. I am happy to report that the company I work for, Azul Systems, was re-elected for a two-year term and we will continue to help develop the Java platform through this involvement.

Java is different to most other development platforms because of one key factor. Hopefully, the JCP will use this to ensure that Java continues to evolve to meet the ever-changing needs of developers and remains the most popular platform on the planet. The key factor? It’s in the name: Community.

Credits: Itweb

Credits: Itweb


In a recent study conducted by on the top 25 jobs with the rarest skills in South Africa, Java developers took the number one spot. Good news for the market is that EOH MC Solutions has started a Java consultancy in Cape Town.

EOH MC Solutions identified a need in the market for Java development, to supplement its very strong .Net competency. Clydie Cronje, who heads up the Business Unit at EOH MC Solutions, says: “We know that Java and .NET are the primary development languages, and as we’re already a leader in the .NET industry, we saw Java as being the next logical step as a business. We’d like to bring the same level of performance, with respect to our strong delivery track record, to the Java skill-set.”

Head of Operations at EOH MC Solutions Beavin De Kock states: “We also identified that none of our competitors in South Africa were providing Java services, in terms of real project delivery. If they are doing something in the Java space, it is pure resourcing.”

EOH MC had a long-standing relationship with Paul Knauer, a leading and well-known expert in this field, and appointed him to establish the consultancy, which started in February 2016. Previously a programme management consultant for Visa, Knauer has a technical background in Java and has been working in this space for over 10 years. Being an early adopter of the scrum methodology, he became a certified scrum master in December 2006 and has also completed a Scaled Agile Framework Practitioner certification in 2015. Knauer has had considerable experience building software development teams both within South Africa, and in countries like the USA, Ireland and India.

“EOH is a strong brand in South Africa with a growing international presence, as well as having roots in the consulting space, making this an ideal challenge for me,” says Knauer.

“The challenge we face generally in the industry, with a lack of skills, is significant, and EOH is well positioned to find creative ways to address this. I enjoy being part of an aggressive company that is constantly looking at innovative ways to address market needs. Starting from scratch means we can build the team we want, in the way that we want, and that appeals to me.”

Looking to 2017, EOH MC Solutions and Knauer have already secured big name clients in the industry, with an upcoming Java Development Shop leveraging the EOH Job Creation Initiative.

Credits: Betanews

Credits: Betanews


New research shows that 98 percent of developers use open source tools at work, with 56 percent revealing that more than half of their development tools are open source, and 18 percent using only open source tools.

The study from code collaboration platform GitLab also shows that more than half of developers (55 percent) are able to choose the tools they work with.

When asked about the tools and techniques that are most important to them, 92 percent say distributed version control systems (Git repositories) are very or extremely important for their everyday work followed by continuous integration (77 percent), chat/collaboration tools (63 percent), agile development (59 percent) and continuous delivery (55 percent).

Security is a key consideration with 86 percent of respondents saying it’s important or extremely important to them when developing code. However, 81 percent report releasing code before it’s ready. The need to hit deadlines (59 percent), pressure from senior management (38 percent), and team turnover (19 percent) are cited as the top three reasons why they release too soon.

Among other findings are that JavaScript is the preferred programming language according to 51 percent of respondents, followed by Python (36 percent), PHP (30 percent) and Java (26 percent). Swift (eight percent) and Objective-C (four percent) are the least popular languages. Developers, it seems, also prefer digital communication, with 66 percent preferring to be contacted via email or instant message, rather than in person.

“Software development is rapidly changing and as this survey demonstrates, there is no ‘one tool fits all’ for modern developers as they adapt the way they work,” says Sid Sijbrandij, CEO and co-founder of GitLab. “While process-driven development techniques have been successful in the past, developers are searching for a more natural evolution of software development that fosters collaboration and information sharing across the lifecycle of a project”.

Credits: Dzone

Credits: Dzone


It was another Monday in the office, testing the next release of our user experience monitoringsoftware. It had been tailwinds towards the release for weeks – everything was progressing nicely. Until the moment I found myself waiting for our Java Agent startup for minutes instead of seconds.

The problem was reproducible – attaching our Java Agent even to a tiny test application increased its startup from two seconds to 30 seconds. My first guess in the hunt for the root cause of the issue was suspecting any of the recent changes in Agent. This guess was quickly dismissed as deployments of previous Agent versions resulted in the very same behavior, which was definitely not present during the previous weeks.

Now I was confused. The Logback library stuck at has been performing the lookups for localhost for ages. The confusion increased when discovering the issue was not reproducing in our test matrix – throughout the dozens of machines in the matrix, everything seemed to work well.

And then it struck – over the weekend, the good old Mac OS X in my laptop had upgraded itself to MacOS Sierra. Due to yet unknown reasons, this started influencing DNS lookups for localhost which now started to take 30+ seconds instead of milliseconds as before.

Thanks to the right keywords now in place, the solution was just one google query away. Apparently, we were not the first ones to be hit by the issue and with the help of StackOverflow, the solution was now at our fingertips.

I do hope this saves some of our Mac-using readers hours of debugging time down the road. And if anyone out there happens to know anyone from the MacOS Sierra team responsible for filesystem / csrutils, let them know that there are a lot of confused Sierra converts who struggle with simple DNS lookups.

Credits: Adtmag

Credits: Adtmag


The election results are in! No, not that election. I’m talking about the 2016 Fall Executive Committee (EC) election of the Java Community Process (JCP).

Each year roughly half the seats of the 24-member EC are up for ratification/election. The EC oversees the work of the Expert Groups that define Java specifications, essentially guiding the evolution of Java. The committee picks the JSRs that will be developed, approves draft specs and final specs, approves Technology Compatibility Kit (TCK) licenses, approves maintenance revisions and occasionally defers features to new JSRs, approves transfer of maintenance duties between members, and provides guidance to the Program Management Office (PMO).

In other words, who sits on this committee matters.

“This was the strongest slate of candidates since I’ve been in the job,” JCP chair Patrick Curran told me when I caught up with him at the Devoxx Belgium Conference last week. (Thank you, Skype.) “It was really competitive this year.”

This is also the first election held under the new JCP 2.10 rules, which, among other things, created two new seats on the committee for unaffiliated individuals. The new Associate Member seats are part of an ongoing effort by the JCP to get more Java jocks involved in the process. The JCP recently introduced Associate Membership, again, aimed at individuals who want to contribute to a Java Specification Request (JSR). There’s no employer approval required and Associate Members get to vote for the two new Associate EC seats.

There are now three JCP membership levels: the new Associate level; the Partner level, which is for Java User Groups and other non-profit organizations; and Full Membership, which is for “legal entities who wish to join Expert Groups, lead JSRs, and/or vote or serve on the Executive Committee.”

Curran says the JCP’s recent recruitment effort has drawn several hundred new members in the past few months, largely in the Associate category. Although Associate membership doesn’t include full JCP benefits, it does provide developers with an opportunity to build their reputations, Curran said.

“Previously the only way to participate in the JCP and get public recognition was to be on an Expert Group,” he said. “Now, Associate members who participate, say, through the Adopt-a-JSR program or their local Java User Group, can get formal recognition for their work.”

The JCP, of course, is the standards-development organization for Java. The organization has been making some serious changes over the past few years through a project calledJCP.Next, and the new seats were part of that effort. JCP 2.10 reclassified two the existing Elected seats to provide for this new type of EC membership. The current EC was formed through JSR 355, which merged the SE/EE EC and the ME EC. The JCP continues to wrestle with the challenge of revising the Java Specification Participation Agreement (JSPA), which Curran has called “big and scary.”

Today, the EC comprises 16 Ratified Seats, 6 Elected Seats, and the 2 new Associate Seats, as well as a permanent seat held by Oracle America, the official steward of Java. The Ratified Seats are filled by Full Members nominated by the PMO; the Elected and Associate Seats are filled by members nominated by Full and Partner Members.

So who got elected this time around?

The first two Associate Members of the EC are Java champion and enterprise software architect Ivar Grimstad, who is a member of the Expert Group for JSR 368 and JSR 372, and a member of the NetBeans dream team; and software architect and designer Werner Keil, who serves as senior test automation engineer at ING-DiBa, and who has contributed his insights to this blog more than once.

I reached out to EC member and London Java User Group leader Martijn Verburg, whose organization was also re-elected this year. I asked him about the EC’s goals for the coming year, and he got back to me via e-mail.

“Our next immediate goal is to work with Oracle and OpenJDK to better align the open source model of development that is Java today (where everything is out in the open) with the requirements of the standards body (needing point in time specifications for purposes of IP flow as much as anything else),” he said. “There have already been some useful early stage discussions, but we’ll have to wait for a few weeks before we can publicly comment. This will be an important step to helping Java get released more often.”

The complete election results are available online here.

Last year I talked with Patrick Curran about the JCP, and one of his comments bears repeating here:

“The strength of the JCP is the fundamentally simple model of a group of interested experts defining specifications through a formal process that includes public review and oversight by an Executive Committee (EC). The process has always been flexible enough not to define exactly how the Expert Groups should do their work. This has permitted a natural evolution (with a little help and direction from the EC in the form of revisions to the Process) from the early days of relatively private deliberations by representatives of large corporations to the current, much more open and collaborative model. It’s a Community Process, and that’s its strength.”

Credits: Gsmarena

Credits: Gsmarena


Today Google is releasing the second (and last) Developer Preview build for Android 7.1. The first one went out last month to the Huawei Nexus 6P, LG Nexus 5X, and the Pixel C. This time around, the HTC Nexus 9 is joining those three devices in receiving the beta software.

The factory images are already up for grabs from Google’s special website, if you know how to deal with those. If not, the easy way is to join the Android Beta Program and then just wait for an over-the-air update to this preview build. That should arrive within a week. The build number is NPF26F for all devices except the Pixel C, which has NPF26H.

This is Android 7.1.1 Nougat we’re talking about here, and the final release of this version will be out in December. It will make its way to Google’s Pixel and Pixel XL, but also to “the full lineup of supported devices”, which according to the company’s initial report in October includes the Pixel C, Nexus 5X, 6P, 6, 9, Nexus Player, and certain Android One handsets.

Android 7.1.1 isn’t going to come with huge updates, as its versioning strongly implies (and also the fact that it’s still called Nougat). It does bring with it support for image keyboards, circular launcher icons, enhanced wallpaper metadata, some new APIs for calling apps, and app shortcuts (which give you options when you long-press on an app in your launcher).

Credits: Zdnet

Credits: Zdnet


On the one hand, businesses want the most stable operating systems. That’s why Red Hathas Red Hat Enterpise Linux (RHEL). On the other, developers want the newest and fastest development tools. That’s why Red Hat also puts out the community Fedora Linuxdistribution. But what if you want both? Red Hat has you covered with Red Hat Developer Toolset 6.

Toolset, along with Red Hat Software Collections 2.3, provides the latest and greatest software tools for RHEL programmers.

Red Hat Developer Toolset helps to streamline application development by giving developers access to the latest, stable open source C and C++ compilers and complementary development and performance profiling tools. It’s available to members of the Red Hat Developer Program. Staring in April 2016, this program also includes a free RHEL developer subscription.

The Toolset enables developers to compile applications once and deploy across multiple versions of Red Hat Enterprise Linux. It is available across multiple architectures with the following Red Hat Enterprise Linux subscriptions: RHEL on x86 systems (Intel and AMD); RHEL for Power; RHEL for z Systems; and RHEL Server for ARM Developer Preview.

Here’s what you’ll get in the latest Red Hat Software Collection:

 The MySQL 5.7 and Redis 3.2 open source databases
  • Perl 5.24 and PHP 7.0, both dynamic open source languages (Perl 5.24 and PHP 7.0)
  • Git 2.9, the latest stable version of the open source software version control system
  • Thermostat 1.6, a Java Virtual Machine (JVM) monitoring tool
  • Eclipse Neon (4.6.1), the latest stable version of the Eclipse integrated development environment (IDE) — Eclipse Neon is also now available as its own software collection and is no longer a part of Red Hat Developer Toolset

In addition, many collections have been updated, including:

  • PHP 5.6
  • Python 3.5
  • Ruby 2.3
  • MongoDB 3.2

The Red Hat Developer Toolset has been updated to include:

  • The GNU Compiler Collection (GCC) 6.2.1
  • The GNU Project Debugger (GDB) 7.12
  • A number of updates to toolchain components and performance tools
    • binutils (2.27)
    • elfutils (0.167)
    • Valgrind (3.12)
    • Dyninst (9.2.0)
    • strace (4.12)
    • SystemTap (3.0)

Both are available now to customers with select active RHEL subscriptions, as well as through the Red Hat Developer Program. Many of the most popular programmers are also available as Docker containers and Docker-formatted images. These containerized programs are available via the Red Hat Customer Portal.

Red Hat is delivering all this programmer goodness because, as Jim Totton, Red Hat’s vice president of the Platforms Business Unit, put it: “To help achieve the benefits promised by modern applications, development methods should include newer, innovative tools, but not at the cost of enterprise IT stability.”

Credits: Motherboard.vice

Credits: Motherboard.vice


Based on code analyses and scans of 50,000 different applications written within the past 18 months, cloud security firm Veracode has compiled a list of the most and least secure programming languages. Software engineers won’t find it especially surprising, with PHP, venue for many a popular and ready-made hack, blowing away the competition.

The report looked as a subset of the most pervasive programming languages/language families used today, including PHP, Java, Microsoft Classic ASP, .NET, iOS, Android, C and C++, JavaScript, ColdFusion, Ruby, and COBOL. Some 86 percent of analyzed programs written in PHP came with at least one cross-site scripting (XSS) vulnerability; 56 revealed at least one SQL injection bug; and 73 percent had encryption issues. Of applications written in the ColdFusion language, which serves a web scripting role similar to PHP and is already fairly notorious in its vulnerabilities, 62 percent revealed an SQL injection bug.

Scripting/web development languages were generally worse off than their more traditional counterparts, such as Java and C++. 21 percent of Java apps were found to have SQL injection vulnerabilities, while 29 percent of applications written within Microsoft’s .NET framework, which serves to unify several different foundational languages in one execution environment (like Java), had the SQL vulnerability.

Of course, different languages are used for different things and in many respects comparing PHP to Java or C++ is apples and oranges. The prior is used to glue the internet together, essentially, while the latter are used more so to develop compiled/executable software. PHP runs within a web browser, while Java (etc.) runs the web browser itself.

But that’s only part of it. In terms of basic design, some languages are just better security-wise.

“It is noteworthy that web vulnerabilities like SQL injection and Cross-Site Scripting are substantially more prevalent in applications written in web scripting languages such as Classic ASP, ColdFusion and PHP, compared to .NET and Java applications,” the report explains. “This is very likely due to differences in the feature sets of each language. There are fewer security APIs built into Classic ASP, PHP and ColdFusion than have been provided for .NET and Java.”

Java, in particular, has what’s known as automated garbage collection. This just means that the language itself (or its execution environment, the Java Virtual Machine) will prevent a program from doing untoward things with a system’s memory. “By removing the need (and ability) for developers to directly allocate memory, languages such as Java and the .NET language family avoid (almost) entirely vulnerabilities dealing with memory allocation, most notably buffer overflows,” the Veracode report explains.

Part of the problem also has to do with who is using these various languages and what they’re level of experience is. Don’t believe the hype: A web development crash course is not going to teach the same stuff as years of computer science education (really).

“.NET and Java programs are typically used by computer science graduates who learned those languages in school,” Chris Wysopal, Veracode’s CTO, told Information Week. “A lot of the scripting languages like ColdFusion and ASP came out of the Web dev world, where you’re designing websites and starting to learn coding, [and] to make sites more interactive.”