This has kind of been discussed by some lately but I think many people are still wondering but don't ask. Java has been around for quite some time now and has infiltrated many a businesses with its simple syntax yet powerful features. A lot of developers still do java and companies have invested heavily into Java, so I feel like it is here to stay. It's definitely starting to lose its luster lately for a few reasons.
One being the state of affairs with Java's creator and a long time guardian of its innovation.
The other being the multiple-processors becoming the norm in computers.
The former by itself has been quite a pain point of the Java community, even before the take-over. JCP has been relatively slow in keeping up with people's needs. Some of the other languages emerging are giving Java a run for its money in terms of the features and paradigms that they offer.
The ruby community (rubyflow.com, rubyinside.com) has been gaining a lot of momentum in the last few years and I really like a lot of the stuff that is going on there. A lot of innovation, the community is really growing and contributing to its growth. It is evolving at a more rapid pace than any other community as of late.
Erlang picked up interest lately because of its distributed nature, fault-tolerance and high-availability, which go hand-in-hand when dealing with communication type of systems.
There are definitely some interesting languages emerging on the JVM itself (JRuby of course being one).
We have Clojure, Scala, Groovy, Fantom to name a few.
From what I see Java is going to be slowly being superceeded by some of these. I know Groovy is definitely being used quite a bit already and the fact that now we have a statically typed version of it called Groovy++, is going to pique quite a bit of interest.
Scala is a really interesting for me personally, because it in a unique position of being a hybrid language. It is both Object-oriented and functional at the same time. Its speed is nearly identical to Java itself.
The akka framework being developed on top of Scala is the most interesting framework for me these days.
Clojure is really interesting too. It is nearly pure functional programming language and its built-in STM gives it a unique feature that not many functional languages have (I don't know if any do actually).
Fantom is one of the new kids on the block, yes I say that even when some of these other languages haven't even been around longer than a few years.
It brings an interesting aspect where the code written in Fantom can compilre for both the CLR (.Net) and JVM. An interesting way to bridge the gap between the two systems.
I have been reading up on all of these languages because I think they will all be players in the game. In fact they already are. Like I said though, I Java is here to stay.
Look at COBOL (I really don't want to compare it to COBOL), but still, if you look at COBOL, it is still around how many years later?
We live in interesting times and I don't think Java developers have to worry about job security, but I do think the circumstances over the last couple of years have spawned some really interesting languages, that people should check out or at least be aware of. If you're a Java developer, I would highly recommend learning at least one of the new languages, as learning is always good for you and it also opens you up to new interesting points of views and paradigms that you may have never even been aware existed.
Monday, April 26, 2010
Monday, January 18, 2010
My humble opinion on what is OSGi's purpose
There was a recent post on theserverside regarding Spring's decision to move spring dm server to Eclipse. There were a lot of posts that I thought sounded like people do not really understand what OSGi is really for and what are its benefits outside of the embedded realm.
www.theserverside.com post:
http://www.theserverside.com/news/thread.tss?thread_id=59183
Here is what I wrote there:
The responses suggest that many people don't consider OSGi a trivial concept.
And at first it isn't, but after reading a bit about it, it actually makes a lot of sense.
The primary issue that enterprise (as opposed to embedded) OSGi tries to solve is the JVM class loading issues.
Secondly, it is the separation of concerns.
As far as the JVM class-loading issue is concerned, I'm sure everyone that has worked with Java to a degree has run into JVM classpath issues, whether its related to having the same package class names, or having multiple jars with slight version variations loaded into the JVM memory.
OSGi allows the developer to specify which exact packages should be loaded into the JVM and even allows multiple JARs with let's say different versions to be loaded at the same time.
However, when you import you are given the option to specify which version of the package that you want to import. This provides much more granularity than just specifying the versions of the JAR files themselves.
When you create a jar, it is good practice to specify the versions of all of the packages that you are exporting as well.
As far as the second issue (separation of concerns), OSGi makes you start thinking about your code in terms of modules. A module should do something very specific.
As an example, you may have one module that has a specific JDBC driver for your database. Another one that deals with DAO layer. Another module that deals with exposing your business logic via REST or SOAP.
Furthermore, a good practice is to split each of your modules into an all interface bundle and one that is all implementation. That way you can swap out your implementation at any time with another bundle at runtime, without compromising your contracts defined in the interface bundle.
As far as the complexity of dealing with the Manifest file, that isn't the case. You actually don't need to change your manifest file directly.
As Stuart mentioned, if you use maven, the felix's maven bundler plugin will help you to manage your relationships of the bundles and packages for you.
You still need to provide which packages you want to import and export.
And another great feature of OSGi is that it allows you to swap out a piece of your functionality without bringing down the server.
In conventional containers the entire web application has to be restarted. With OSGi, nothing is down and only a piece of your code is actually refreshed with newer code.
www.theserverside.com post:
http://www.theserverside.com/news/thread.tss?thread_id=59183
Here is what I wrote there:
The responses suggest that many people don't consider OSGi a trivial concept.
And at first it isn't, but after reading a bit about it, it actually makes a lot of sense.
The primary issue that enterprise (as opposed to embedded) OSGi tries to solve is the JVM class loading issues.
Secondly, it is the separation of concerns.
As far as the JVM class-loading issue is concerned, I'm sure everyone that has worked with Java to a degree has run into JVM classpath issues, whether its related to having the same package class names, or having multiple jars with slight version variations loaded into the JVM memory.
OSGi allows the developer to specify which exact packages should be loaded into the JVM and even allows multiple JARs with let's say different versions to be loaded at the same time.
However, when you import you are given the option to specify which version of the package that you want to import. This provides much more granularity than just specifying the versions of the JAR files themselves.
When you create a jar, it is good practice to specify the versions of all of the packages that you are exporting as well.
As far as the second issue (separation of concerns), OSGi makes you start thinking about your code in terms of modules. A module should do something very specific.
As an example, you may have one module that has a specific JDBC driver for your database. Another one that deals with DAO layer. Another module that deals with exposing your business logic via REST or SOAP.
Furthermore, a good practice is to split each of your modules into an all interface bundle and one that is all implementation. That way you can swap out your implementation at any time with another bundle at runtime, without compromising your contracts defined in the interface bundle.
As far as the complexity of dealing with the Manifest file, that isn't the case. You actually don't need to change your manifest file directly.
As Stuart mentioned, if you use maven, the felix's maven bundler plugin will help you to manage your relationships of the bundles and packages for you.
You still need to provide which packages you want to import and export.
And another great feature of OSGi is that it allows you to swap out a piece of your functionality without bringing down the server.
In conventional containers the entire web application has to be restarted. With OSGi, nothing is down and only a piece of your code is actually refreshed with newer code.
Subscribe to:
Posts (Atom)