The future of java

Java’s future will be constrained by the bounds of Oracle’s business model.

Drama has been running high since Oracle began to shape up the Java technology it acquired along with Sun Microsystems. Oracle ended the impasse over a new core Java release, set out a road map for the next two years, and began reorganizing Java’s ineffectual governance. Oracle’s Java road map and commitment to invest reassured enterprise customers and prevented a split with IBM but alienated many in the open source community. But Oracle’s plans so far fail to address Java platforms’ inherent complexity, which remains Java’s Achilles’ heel in head-to-head competition with Microsoft’s.NET platform. Moreover, a controlled, top-down innovation model will limit Java’s role as the basis for the “cloud” generation of platforms, rich Internet applications, and new development techniques ranging from languages such as Ruby to approaches such as business process management (BPM) and business rules. Conclusion: Java’s future in the enterprise is alive and well but limited.

Oracle’s strategy for Java will change the Java ecosystem that has existed for 11 years.

  • Oracle will direct Java innovation. Oracle has made it clear that from this point forward, it will direct all innovation in core Java (Java SE). Oracle will happily accept the contributions of others through OpenJDK as long as those contributions align with Oracle’s priorities.
  • OpenJDK is not fully open. OpenJDK is covered by a General Public License (GPL), and though it’s certainly true that there are alternative JVM implementations and derivatives out there, OpenJDK is not open in spirit: It’s practically impossible to distribute an alternative implementation without Oracle’s sanction — specifically without a grant of the Java TCK. Losing The Apache Software Foundation as a supporter also hurts Oracle’s credibility as a partner with the Java alpha geeks who drive so much independent and discontinuous Java innovation. Those developers will take their energy elsewhere, probably to Apache projects.
  • The JCP is dying. The Java Community Process remains in place, but we believe that Oracle will formulate an alternative that ends the fiction of JCP as an open process and streamlines the process of Java platform evolution. The result will be total domination of Java’s evolution by Oracle and IBM.
  • Competition will shift to frameworks. With Oracle directing innovation at Java’s core, others in the Java ecosystem will focus on higher-level frameworks. This shift began years ago, but we now expect it to intensify. We expect most of the work on frameworks to focus on the enterprise, as that is clearly Oracle and its core partners’ focus with Java.
  • Fewer young developers will learn Java first. One of Java’s greatest strengths has been the number of young developers who learn it as a first language. As Java becomes less and less of a client-side language, we expect to see educational institutions switch to other languages for primary education, ones with stronger client-side representation such as JavaScript and HTML 5. Over time, developers will begin to view Java as a server-side language for enterprises — like COBOL.

These ecosystem changes will have minimal immediate impact on customers. Java SE 7 and 8 will move forward, driven by the strong consensus among Oracle’s partners about the content of those releases. Customers will see predictable and stable enhancements of enterprise Java middleware. But Oracle and its close Java partners are in a classic “innovator’s dilemma.” It may take a decade, but the bottom-up innovation the open source community drives will find expression elsewhere, and smaller companies that Java’s high-end capabilities do not serve well will gravitate toward a new “good enough” open platform — likely based on a combination of LAMP and HTML 5 open standards.

Yet another doom and gloom prediction…

Java has become a success story for 10 years way before it became open source three years+ ago.

It didn´t became successful just for being “open” (which it is now) but because it delivers on the promise of cross-platform compatibility.

It´s funny that you say that Java as a client tech will lose momentum when hundreds of thousands, if not millions of people use desktop Java software on a daily basis, like Vuze and jDownloader.

Every one of your “points” is nothing more than repetition of what many “pundits” have been saying for the last year, and every of their doom and gloom predictions has turned being wrong: Oracle didn´t kill, Oracle didn´t kill MySQL, Oracle is investing in all these along with Glassfish, Virtualbox and almost every other open source project from Sun, with the obvious exception of Opensolaris.

Oh, one last thing: Who uses Apache´s Java? no one. H*ck, after Java SE 6.0, even IBM´s JDK became irrelevant.

Java is thriving and is not “complex” Java EE is complex, it needs to be tu run mission-critical systems. Java SE can be as easy as you want. People can run common scripting languages on top of Java like Jython (Python on Java), JRuby (Ruby on Java), NetRexx and others.

Java is much more than a programming language: it´s a runtime environment and you can use Java without actually writing Java.

Blowfish, the name of the blog

Blow fish is a name of a cipher algorithm used in UNIX Operating system.

Brief description of the algorithm

Blowfish is a keyed, symmetric block cipher, designed in 1993 by Bruce Schneier and included in a large number of cipher suites and encryption products. Blowfish provides a good encryption rate in software and no effective cryptanalysis of it has been found to date. However, the Advanced Encryption Standard now receives more attention.

Schneier designed Blowfish as a general-purpose algorithm, intended as an alternative to the ageing DES and free of the problems and constraints associated with other algorithms. At the time Blowfish was released, many other designs were proprietary, encumbered by patents or were commercial/government secrets. Schneier has stated that, “Blowfish is unpatented, and will remain so in all countries. The algorithm is hereby placed in the public domain, and can be freely used by anyone.”

Notable features of the design include key-dependent S-boxes and a highly complex key schedule.



  • 1 The algorithm
  • 2 Cryptanalysis of Blowfish
  • 3 Blowfish in practice

The algorithm

Blowfish has a 64-bit block size and a variable key length from 1 bit up to 448 bits. It is a 16-round Feistel cipher and uses large key-dependent S-boxes. In structure it resembles CAST-128, which uses fixed S-boxes.


The Feistel structure of Blowfish

The diagram to the left shows the action of Blowfish. Each line represents 32 bits. The algorithm keeps two subkey arrays: the 18-entry P-array and four 256-entry S-boxes. The S-boxes accept 8-bit input and produce 32-bit output. One entry of the P-array is used every round, and after the final round, each half of the data block is XORed with one of the two remaining unused P-entries.

The diagram to the upper right shows Blowfish’s F-function. The function splits the 32-bit input into four eight-bit quarters, and uses the quarters as input to the S-boxes. The outputs are added modulo 232 and XORed to produce the final 32-bit output.

Decryption is exactly the same as encryption, except that P1, P2,…, P18 are used in the reverse order. This is not so obvious because xor is commutative and associative. A common misconception is to use inverse order of encryption as decryption algorithm (i.e. first XORing P17 and P18 to the ciphertext block, then using the P-entries in reverse order).

Blowfish’s key schedule starts by initializing the P-array and S-boxes with values derived from the hexadecimal digits of pi, which contain no obvious pattern. The secret key is then, byte by byte, cycling the key if necessary, XORed with all the P-entries in order. A 64-bit all-zero block is then encrypted with the algorithm as it stands. The resultant ciphertext replaces P1 and P2. The same ciphertext is then encrypted again with the new subkeys, and the new ciphertext replaces P3 and P4. This continues, replacing the entire P-array and all the S-box entries. In all, the Blowfish encryption algorithm will run 521 times to generate all the subkeys – about 4KB of data is processed.

Because the P-array is 576 bits long, and the key bytes are XORed through all these 576 bits during the initialization, many implementations support key sizes up to 576 bits. While this is certainly possible, the 448 bits limit is here to ensure that every bit of every subkey depends on every bit of the key,[2] as the last four values of the P-array don’t affect every bit of the ciphertext. This point should be taken in consideration for implementations with a different number of rounds, as even though it increases security against an exhaustive attack, it weakens the security guaranteed by the algorithm. And given the slow initialization of the cipher with each change of key, it is granted a natural protection against brute-force attacks, which doesn’t really justify key sizes longer than 448 bits.

Cryptanalysis of Blowfish

There is no effective cryptanalysis on the full-round version of Blowfish known publicly as of 2011. A sign extension bug in one publication of C code has been identified.[3]

In 1996, Serge Vaudenay found a known-plaintext attack requiring 28r + 1 known plaintexts to break, where r is the number of rounds. Moreover, he also found a class of weak keys that can be detected and broken by the same attack with only 24r + 1 known plaintexts. This attack cannot be used against the regular Blowfish; it assumes knowledge of the key-dependent S-boxes. Vincent Rijmen, in hisPh.D. thesis, introduced a second-order differential attack that can break four rounds and no more.[1] There remains no known way to break the full 16 rounds, apart from a brute-force search.[4]

Bruce Schneier notes that while Blowfish is still in use, he recommends using the more recent Twofish algorithm instead.

Blowfish in practice

Blowfish is a fast block cipher, except when changing keys. Each new key requires pre-processing equivalent to encrypting about 4 kilobytes of text, which is very slow compared to other block ciphers. This prevents its use in certain applications, but is not a problem in others. In one application, it is actually a benefit: the password-hashing method used in OpenBSD uses an algorithm derived from Blowfish that makes use of the slow key schedule; the idea is that the extra computational effort required gives protection against dictionary attacks. See key stretching.

Blowfish has a memory footprint of just over 4 kilobytes of RAM. This constraint is not a problem even for older desktop and laptop computers, though it does prevent use in the smallest embedded systems such as early smartcards.

Blowfish was one of the first secure block ciphers not subject to any patents and therefore freely available for anyone to use. This benefit has contributed to its popularity in cryptographic software