With minimal introduction, just want to say, every Java developer in the world needs to hear Java Posse 160… if you want to, skip 18 minutes into it and start from there.
To borrow from John Hodgman…. that is all.
CARVIEW |
With minimal introduction, just want to say, every Java developer in the world needs to hear Java Posse 160… if you want to, skip 18 minutes into it and start from there.
To borrow from John Hodgman…. that is all.
Bruce Eckel says Java is at an “Evolutionary Dead End”. His perspective is that retrofitting newer features into Java is making it absurdly complex. He states the choice is between no more evolution or breaking away from the past. In any other scenario he suspects things are only going to get worse. As a passing by remark, he proposes moving on to Scala as an exit strategy, if Java continues to evolve while honoring backward compatibility.
Technically his point is valid, realistically what are the millions of Java developers who build Java applications at thousands of enterprises going to do if they can’t incrementally take advantage of some of the newer features? It may be possible for Ruby or even Python to radically break away from its earlier versions and start on a fresh slate because not only do they have lesser number of deployments but on an average they have programmers smarter than the average corporate journeyman.
Java has evolved from being a replacement for C++ to an all pervasive cross domain programming language. One of the primary reasons for this growth has been the abundance of features, availability of commercial and open source implementations of these features and wrapping up of these features in all sorts of APIs, with the assurance of stability.
If we drop everything and restart, won’t Java be a completely new language? How would we guarantee we get everything right this time around? Which portions of Java will benefit from reinvention the most? What will we do while we are busy reinventing, knowing what we are doing is soon to be rendered obsolete — it won’t get done in a jiffy in any case?
In a recent interview Dr. Gosling said -
“If you look at something like Flash, when you get to the much more advanced stuff — with richer interfaces, more complex network protocols, more complex APIs — it really falls short.”
Source : Redmond Developer News
While, I would agree with Dr. Gosling, that the Flash VM, the ActionScript library and the Flex framework is not a be-all and end-all RIA solution (remember that its incarnation as a application developer’s tool — as opposed to a designer’s easel — is fairly recent and it is continuously and rapidly evolving as we speak!), I have a feeling Dr. Gosling is actually saying that the grapes are sour ! (For those who may not be familiar with the fable of the The Fox and the Grapes read on and you will quickly see the connection.).
At this time in its current form and shape Flex is a great option. Further, far from being competitive, at Saven Technologies, we have experienced that Java and Flex are complementary and can help build rich interfaces fairly effectively. Let me explain some more of this, but before that let me dissect Dr. Gosling’s comments and set the context.
Dr. Gosling has specifically pointed out that the shortcomings are related to support for networking protocols and complex APIs. My reply — TCP and UDP are two popular transport level protocols. Flash supports TCP. It does not support UDP. At the application level Flash supports HTTP and HTTPS. It supports AMF, which is a SOAP like but more efficient message format, and RTMP, which helps stream audio, video and data across the Internet. It does not support many application level protocols including SMTP, POP3, RTCP and many more. With the protocols in Flash repertoire one can build most consumer applications that utilize HTTP, Web Services and RESTful constructs.
One of our financial services clients was not satisfied with this. Not only did they want remote procedure calls, they desired real time data push and secure connectivity. With the help of LifeCycle Data Services, a server side integration technology that runs without a fuss in any Java application server, and the protocols mentioned above (AMF and RTMP), we could easily achieve what our clients desired. LifeCycle Data Services has open source cousins — BlazeDS, GraniteDS and more.
So while Dr. Gosling is right that Flash does not support as many protocols as Java does and he is also right that it does not have direct support for complex APIs, let’s say for messaging systems or database connectivity, the question is that does flash (with its Flex framework) really fall short because of the lack of these. Not really, on the contrary it piggyback on Java and PHP and others for such extensions. We are primarily Java experts who graduated to using Flex as the RIA and we see no trouble in leveraging the Java infrastructure that is so rich and robust. In the application that I was talking about earlier, that required real time updates, we used JMS for subscribing to the market data feed publications. Flex messaging and JMS worked well together and it was just fine.
Finally, Java Applets has support for many networking protocols and complex APIs, then why is it falling short of expectations? Weren’t there other things, including the well known JRE version mismatches that brought it down? Why is Sun creating JavaFX if the most critical ingredients — at least the way its worded it makes me believe that these are so — are already brewed in?
I feel very disappointed when a person I deeply respect and revere needs to make such comments. Java as a language and platform is very comprehensive, user friendly and productive (despite all the noise from the Rubyists) and works in harmony with many other technologies, including Flex. If JavaFX and the Consumer JRE deliver the promise I am happy to adopt it, as I have adopted Applets, Swing and the Java web application technologies so far.
Just a quick note, and excusing my pun, I think we all would like to wish Knuth a (belated) 70th Birthday
Gosling dragged the crew into the Dirty Dirty for the second (annual?) Sun Tech Days Atlanta. Last years STD I was pretty down on. It is 100% recycled JavaOne content from 9 months earlier. This years had a better mix with a good bit of new content. One comment from the other Manheim people that were there is they had a general feeling that it was better organized and orchestrated this year. I think that is fair, but I didn’t notice a huge difference. The event was also expanded to include tracks for Solaris development and administration, which was good too. There was some good stuff there even if that wasn’t your field directly.
One thing, though. I want to say to Sun…again.
TAKE POWERSTRIPS WITH YOU.
Jeez. JavaOne, STD, doesn’t matter. There seems to be a critical shortage of places you can plug in your laptop at all of these events.
Anyway, the one big complaint I had was the feeling of Bait and Switch I got from the whole EE program. Last years was bad because it was all intro to stuff that was so old everyone in the room had already seen it. This years was the exact same thing, the difference is they titled the affairs like they were going to be legitimately interesting. One session about “Everyday webservices: Metro and Rest,” where you expect to see the new JAX-RS stuff from metro was… wait for it… all SOAP and WS-* and the same demos I have seen 3 years running with a brief bit on RESTat the end. I didn’t even see the REST bit because I didn’t want to sit through 40 minutes of old content for 10 minutes of new. The “SOA Grid Computing” Oracle session (hey, doesn’t that sound great?) Literally started with and intro to WSDL. “Are you frakking kidding me?” was the general response from my compatriots.
One the flip side, the Glassfish session was really good, and my group seemed to get a lot of good information out of it. The features list for GF3 is so long that just getting a handle on what is there is going to be an issue for a lot of people. I kind of wish there had been a little more tech content there, but it was generally good. The SE6uN session was good, and Rags was once again in good form as a speaker. All of the evangelists seems at least a little more comfortable with what they were doing over last year. There were also session on JRuby on Rails, which I wanted to go to but had to duck out for to get back into midtown for…
Sort of heels of Sun Tech Days, the GWT team had a meetup with the team and a few external developers to discuss the road map for GWT in the future. We are all waiting for GWT 1.5 to drop, promising another round of big compiler optimizations such as expansion/in lining of methods and the much anticipated support for SE5 language constructs. All in all it was a good chat.
The Google meeting was a good idea, especially since STD now seems to be becoming a regional event. I can’t help but wonder if next year we will see more things orbiting around STD as a mini-JavaOne.
If you are interested in learning more about Adobe Flex or understanding how it could be integrated with other technologies, including Java, then please come to Flex Camp Chicago. Its a day long event at the Illinois Technology Association in downtown Chicago on January 18, 2008.
Hope to see you there!
If you haven’t already, be sure to read Steve Yegge’s post on his experience of dealing with large code bases (it’s a bit long post but an excellent read).
He explains the maintenance nightmare of his 500.000 lines of code game written in Java and quite correctly concludes that code size is a crucial problem for big software projects.
Let me start by wishing everyone a happy new year ! I hope 2008 is prosperous and peaceful for all of you. For many of you who still take pride in being a Java developer, I also put down a list of top 5 expectations from the year that has just started. It may be presumptuous on my part to create a single list of top 5 expectations for the eclectic world of Java developers but none the less I will do it! Some of you will agree, some of you will vehemently disagree and the rest will remain silent. In all the cases though I hope to provoke you to think about what you want and desire from the language and platform that you are so intently connected with.
So let’s get started -
1. JavaFx transforms from hype to reality
In 2007 starting with JavaOne, we all heard that the messiah has arrived in the form of JavaFX. Unfortunately, the entire promise is taking too long to manifest into a real option. Hope 2008 either converts it into a real, simple and viable option, so that Java developers don’t necessarily need to take refuse in the alternative rich interface technologies, or just brings all the hype to an end.
2. Glassfish enters the application server choice bundle.
Glassfish is a fantastic open source Java application server and platform. It was the first one to be compliant with the Java EE 5 standards. It has implemented almost everything that the JCP is churning out. It works and it is powerful. However, it still remains an unknown application server in the enterprise. Most managers have never heard of it, many Java developers have never bothered to download it and many others think its not a serious option, even without checking it out. Hopefully developers start taking its advantage in 2008.
3. Lightweight/Heavyweight discussion is put to rest
With Java EE adopting many of the advantages of frameworks, tools and libraries that figured out how to do things in a simple and straightforward manner, the divide between the so called traditional heavyweight Java and its lightweight alternatives is blurring. However, many of the staunch believers and promoters of the lightweight frameworks are not letting the debate rest to peace. May these folks find something more useful and new to champion ! Also, those who switched sides altogether in favor of those dynamic options, beyond Java, that was supposed to cleanse them of all evil may return once they find that their simple framework fails to deliver simple database manipulations or relies on your same old ways to integrate with other things in the enterprise.
4. Google likes Java, somebody convince Apple too :)
The iPhone is popular and many iPhone applications are being built. So far Java is poison for Apple. Hopefully things change this year. Hopefully Java developers gain from this surge! Google has already helped the world of Java developers with its numerous open Java APIs and services. Its has also reinforced that when the winner adopts you, you flourish and proposer! So its not as much about being with Apple the company but its about being in the winner’s camp.
5. Unify some and sunset a few others
Plurality in the world of Java provides ample choice to do even the most mundane of tasks but it often leaves Java developers confused in the middle of this abundance. Java developers for a few years now spend a considerable amount of time contrasting and comparing the numerous commercial and open source frameworks, tools and libraries to get their job done. Hopefully, 2008 sees some of these projects merging and some others just waning into obscurity. Hopefully the feudal lords realize that although dictatorship is detrimental, a unified nation state has its benefits.
Thats all for now!
Speak up! Say whatever you have to say, its all about what you want:)
Once again, a happy new year!
Contact Us | Advertise with Us | Privacy Policy | Press Center | Jobs
Weblog authors are solely responsible for the content and accuracy of their weblogs, including opinions they express,
and O’Reilly Media, Inc., disclaims any and all liability for that content, its accuracy, and opinions it may contain.
This work is licensed under a Creative Commons License.
For problems or assistance with this site, email help@oreillynet.com | (707) 827-7000 / (800) 998-9938