Java 8 backwards compatibility

I really hope that Oracle JVM engineers will decide to ignore backwards compatibility for Java 8 release. It is a great burden for the language in past releases and for developers too. The language is and was overly complicated and honoring backward compatibility is totally counterproductive.

For instance, consider Generics that were introduced in Java 5. It came with Type Erasure due to backwards compatibility with Java 1.4 and it was delivered exactly 7 years ago. The problem relates to the fact, that JVM engineers hadn't free hands and came up with quite complicated solution that often even the smart dudes don't get at some point. Type Erasure vanishes all dynamic type information that you could otherwise use in runtime, especially in some data binding libraries for instance. All static type information in class declaration are available via reflection :

   public class Test implements Superclass<String> { 
        // String retained, accessible via Class.getGenericSuperclass()
        
        // Integer retained (via Field.getGenericType())
        private List<Integer> l;

        // Long retained (via Method.getGenericParameterTypes())
        public void test(List<Long> l) {} 

        // Character retained (via Method.getGenericReturnType())
        public List<Character> test() { return null; }
    }

but dynamic type information is erased. If you create a class instance that carries dynamic type information T, there is no way to resolve that in runtime, speaking of JVM built-in ways of course.

public class Feed<T extends Entry> {
        // T is dynamic, only known at runtime
 public List<T> entries = new ArrayList<T>();
        Object o = new ArrayList<String>(); // String erased
}

There are workarounds like Super Tyle Tokens and Type Literals that are utilized in Guice - TypeLiteral or Jackson - TypeReference. So that you can create anonymous class with static Type information :

       // now the Type is obtainable
       TypeLiteral<List<String>> list = new TypeLiteral<List<String>>() { };

that is passed into method instead of List<String>.class (that won't compile) and that can be used to resolve the type via reflection later. This was practically one of suggested new features for Java 7 - enhancing java.lang.reflect.Type with generics as it was done with java.lang.Class. Then List<String>.class would be Type<List<String>>. But it didn't make it through. It would be a "patch" anyway.
    A patch for design flaws caused be tolerating backwards compatibility for two releases with distance decade long from each other. Even after 7 years the design decisions that were made were highly influenced by the fact that Java 7 must be backwards compatible with Java 4. Why ??? If a company has an old java 4 project, why would it have jvm 7 on the production server, it won't do for a year at least anyway even if it is said to be 100% backwards compatible. The company just shouldn't deploy java 7 apps in there, that's it. Why the heck it is necessary to make language design restrictions because of that. Well, I must admit that I understand these decisions a little bit in case of Java 7, but I really hope in lesser backwards compatibility in Java 8. It's a simple question : do we provide companies with the comfort of running apps/libraries that are 10 years older/younger that each other OR we lighten the burden on developers shoulders and make the language less complex and easier to use... I say f*** the companies...These attempts to make apps live longer than 10 years has no sense. If it is framework, platform or so and it is successful it would be refactored x times in the mean time. If it is a banking software, f*** it, rewrite it using brand new technologies for the same costs that would be spent for its maintenance.

I mean if I find myself upset about some serious design flaws in project Lambda in 2013, that exist just because of backwards compatibility with java 1.4, I will be really disappointed.

A lot is happening these days and Oracle must pay a very good attention to keep up. Take a look at the role of scripting technologies both on client and server side. Google came up with its V8 javascript engine which is utilized by Google Chrome and can be used by anyone because of its framework nature. Node.js is using it. Very successful Google Web Toolkit for building enterprise UIs deploys client side part of apps for Javascript engines. Oracle responds with project Nashorn in this area. Nashorn Javascript Engine will be a successor to Rhino engine that serves mainly for server side JS compilation into bytecode providing reflection and other cool things. YUI compressor is using it. And guess what, Google is introducing Google Dart with the goal to replace javascript, providing even cross compiler that will be able to compile Dart to ECMAScript 3 on the fly. Google was encouraging other browsers to integrate a native VM into their engines which is in progress in Google Chrome now.
   This all shows how Java and JVM is important and almost immortal, but also it shows how it can be avoided in various areas and substituted by C/C++. V8 engine would be a really suitable adept for JVM, though C++ was chosen for its implementation, maybe because it is used by Chrome. Future of Javascript is to be threatened by Google Dart in far future though Oracle is working on new Javascript Engine implemented from scratch. etc. etc...

A lot of reasons for preferring platform evolution over backwards compatibility, isn't it ?

Broadleaf Commerce Vs. Apache Ofbiz

At first, around 2-3 years ago, I gave up on using Apache Ofbiz, because it seemed that I wouldn't be able to be "productive" with it for weeks, because of its complexity. But I noticed of Broadleaf Commerce a few months ago and I find it very interesting. The technology stack suits me a lot ( spring, spring-mvc frontend, GWT backend, hibernate on jpa spec, maven, etc.), if it utilized git and github.com for SCM, I wouldn't have anything to criticize. On the other hand they got rid of flex from backend which makes me happy :-) The principle of building customized shopping cart on this platform is very straightforward, but it expects a developer with some experience too.

First off, I'd like to mention that e-commerce out-of-the-box solutions (this applies especially for non-US businesses) are simply not able to fulfill specific needs. If you look around, you see tons of PHP shopping carts (install & go) that allows you to run a cart, but you have to live with all the disadvantages that result from the "universality" of the solution. Payment, taxes, accountancy and shipment is locale specific. They have mostly terrible architecture, missing modularity, horrible UX and tons of other idiosyncrasies...  Prestashop is not that bad from what I've seen and been told.

Then there are Java e-commerce solutions like partially opensource Konakart or opensource shopizer and jadasite. Jadasite looks quite alright, but it is out-of-the-box, it doesn't even have a shell or ant script, no maven...imagine you would need to change payment or shipment module... no way. I just refuse to work with applications that depend on eclipse WTP anyway...

And finally, there are solutions like Apache Ofbiz and Broadleaf Commerce. They are not out-of-the-box solutions (well broadleaf coffee shop demo is almost production ready for US), but rather platforms. A  developer utilizes them to put a custom solution together, not develop/program/code but rather "put it together", which means : infrastructure setup, beans/services/entities adding, overriding, merging, extending or changing an existing module to adjust it to a concrete region, etc. Complexity of Apache Ofbiz makes you waste a lot of time, in my opinion. Unless you are being paid for that familiarization, it's a big problem. As to Broadleaf commerce, I find it much easier. The documentation could be more actual / current though. But I think that for a developer who is new to these two platforms, choosing Apache Ofbiz means much more investigating and learning the internal working than the actual results and it is very demotivating. But in regards to Broadleaf Commerce, I kinda see everything after 2 hours of reading through the codebase.

I tried to investigate Ofbiz and I came to conclusion, that for my needs (shopping cart) it is not worth it. Its entity and service engines, workflows etc. and the way you're setting up the platform seemed very J2EE non-standard and I felt lost! Then I realized that it is probably inevitable, because how else should e-commerce platform of this caliber look like? It just can't be done as it is in Broadleaf commerce. You simply have to spend  weeks learning how to become productive with it... Whole weeks ? Yeah I'd have to deliver the entire e-commerce cart myself. It's advantage is that it is 10 years old, it is roofed by Apache foundation and it has relatively big community around. The disadvantage is, imho, that its main contributors are employees of companies that doesn't allow radical changes to it which causes defensive programming and not much of a radical refactoring that would be beneficial for the platform (at least I got the impression). This is not a problem for experienced Ofbiz developers, but it's quite a roadblock for newcomers.

I spent a couple hours looking at source base of Broadleaf Commerce and I see very clearly what would need to be done to setup a maven project (webapp) that represents e-commerce cart and that just deploys to a container with broadleaf platform libraries as dependencies and works ! You can see that a few minutes after svn checkout ! There is a demo project that you are supposed to copy/use as your new site/eshop. You  just override/add/merge what you need to (controllers, services, entities, jsp, css, entire modules) simply via spring configuration or filesystem changes and this way you build up your custom e-commerce cart. There is one thing that I would appreciate though : in addition to the demo site there should also be a maven archetype with default/classic template, infrastructure setup and default workflows and modules, that a developer just deploys and starts to modify. Or a theme or two would be nice. Another important point to mention is, that a good knowledge of Google Web Toolkit is great advantage, because you need it for developing backend / administration. Also Broadleaf Commerce seems to be easily deployable to Cloud Foundry for eventual scaling or other cloud-like needs. And finally, I think that this is the only and ideal e-commerce solution that would be relatively easy to integrate with Portals like Liferay or WebSphere and I'm not talking about just embedding it, but about building an e-commerce cart portlet with Broadleaf framwork. It would be tough integration job, but there is definitely no better or suitable candidate for that.

I would like to see and I wish Broadleaf Commerce a growing community because this software deserves attention.