For some time now I have an idea to start up a Java User Group (JUG) in my hometown. It is still on a level of idea but I’ve started to talk about it with some of the colleagues from local development community. Let’s see. Maybe it will happen some time soon. During my research on the internet, to see how other guys are doing it, I’ve encountered to a virtual Java user group (vJUG or virtualJUG, http://virtualjug.com), which has a global, worldwide level. I was keen to join and become a part of such a community. On top of that, I was very positively surprised when I saw what presentations are held and the speakers who presented them. James Gosling (creator of Java), Simon Ritter (since recently the head Java Evangelist at Oracle), Dr. Venkat Subramaniam (award-winning author, founder of Agile Developer, Inc., an instructional professor at the University of Houston), Matt Raible (technology evangelist, founder of AppFuse)… to name a few. A lot of quality stuff there. It’s like an online Java conference all year long. And for free.
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.
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.
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.
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.