Yearly Archive: 2015

Programming Hints > 2015

Java 8

Moving from Java 6 to Java 8

27/12/2015 1 Comment

Many of us are working on Java projects which have started some years ago. It is likely that those projects are implemented in Java 5 or 6 and are planned or already migrated to the latest version of Java. The most obvious reasons for moving from Java 6 to Java 8 are new language features and security improvements. Aside to this, Java 8 is a bigger milestone in the Java programming language history and brings Java development to a completely new level.

You can jump in and start coding in Java 8 using your previous Java programming experience. Code will compile, for sure. Java 8 is backward compatible with previous versions. But you will not be able to get advantage of the new features and new concepts without taking some time to explore and learn about them. There are many web sites describing new Java 8 features in detail, I would like here just to briefly list them. But, before that, I would recall important Java 7 features, which you may not had a chance to use, but could be quite handy.

Read more about Java 8 (and Java 7) features

Java

Internal iterations

Internal Iterations in Java 8

14/12/2015 1 Comment

Most of us learned in school to program in an imperative/structural/procedural way. Object oriented programming is also a type of procedural paradigm. In that context, when we are working with collections, we are iterating through them with some kind of for or for-each loops. We are telling the program how to perform the iteration and (within the loop) what do to with each processed element from the collection. Those is called external iteration. On the other side, in languages which support functional programming, you should focus only on ‘what’ and the underlying collection will take care of ‘how’ to perform iteration. Those are called internal iterations.

Read more about internal iterations in Java 8

Java

,

Estimates vs #NoEstimates

Estimates vs #NoEstimates, my experience

09/12/2015 0 Comments

Some time ago, I’ve heard about a new movement (or approach), to do software development without using estimates. There are many Estimates vs #NoEstimates ongoing debates on the internet. At first, it sounds like a renegade approach. Like there are some rebels against corporate “written in stone” base principles and rituals. On the second though – maybe it could make sense. Either way, it definitely makes you think about all the dust raised by the topic.

I have participated in many different type of software development projects, which involved some kind of estimations. Those were either standard task time estimations or an estimations in a form of story points. But, recently, I’ve realized that I’m actually also part of a “no estimates” kind of a project. For years.

It was not like this at the start of the project. Back than we had MS Project files updated few times a week, based on our task (re)estimations. But at some point, customer decided not to do them anymore.

Read more about how we stopped doing estimations

Agile

,

Diffie-Hellman public key

Diffie-Hellman public key issue

29/11/2015 0 Comments

If you are developing web applications that use HTTPS, it could happen to you this year (2015) that, all at a sudden, your browser refused to open the pages from your very own web application. And all this because some Diffie-Hellman public key, which appears to be weak. E.g. if you are using Google Chrome browser, most probably you started to see this problem after upgrading Chrome to version 45. The error message:

Server has a weak, ephemeral Diffie-Hellman public key

It actually means – your server’s DHE (Diffie-Hellman ephemeral key agreement) cipher, that allows Internet protocols to agree on a shared key, has less than 1024 bits. It is described in detail at weakdh.org. This problem could compromise connection security by the men-in-the-middle attack Logjam.

As of Java applications, and I assume your project uses Java 6 or Java 7, the main problem is that your application server (e.g. Apache Tomcat) is using by default Java Security Socket Extension (JSSE), which has it’s own DHE parameters which are 768-bit. This is considered weak and most recent versions of the browsers will refuse to establish a secure connection with your application server.

Read more about the options to fix this problem

Java

, ,