As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am a long time Java developer on JBoss(and Tomcat). In the last year I had to develop over WebLogic and I have to say - I really miss JBoss.
Since my experience with WebLogic is pretty shallow, I am asking the more experienced guys out there:
Is there a reason for spending money on WebLogic?
Isn't JBoss giving you all that you need?
I suspect the reason Weblogic gets chosen is a pleasant sales person comes to visit a manager with money to spend, gives him the sales pitch and hey-presto, the company is using Weblogic. I don't know if the JBoss support contract comes with a sales force, but would be surprised if it did and that the playing field has leveled in that respect.
In my experience, other than the pretty console you get with Weblogic (which isn't worth forking out the license fees for) there's not much between the 2. I suspect these days JBoss has market share (just guessing that), which in my book that translates into more help available online, etc when you're stuck on something.
It's also worth considering that the Weblogic licenses (last time I saw them) where the usual server-side terms - per-processor, per-box, etc. This will limit you in scalability terms because with JBoss you can keep adding hardware without occurring extra cost, while with Weblogic your licenses will need upgrading too.
Whichever you choose you're going to be able to build your system on top of them without too much trouble, but my preference would be JBoss.
I really like WebLogic. I'll suspend the licensing cost for the moment and just say that in their heyday they were the best Java EE app server on the market, hands down. BEA had a lot of extremely talented people developing their code, and it showed. If money was not part of the equation, and I had an employer that insisted on spending money that wasn't mine, I'd still choose WebLogic over WebSphere or JBOSS or Glassfish or anything else on the market.
I'm saddened by Oracle's purchase. I think that the talent has leaked away, and Oracle has no clear idea of what they want to do with WebLogic. They've been stuck on version 10.1 for a few years now.
<prejudice-ahead>
Glassfish sounds like it's a much better effort from Sun, but their history says they write great standards and lousy implementations. I don't consider Glassfish to be a viable alternative.
</prejudice-ahead>
WebSphere is a typical IBM project: twice the cost, half the functionality, poor documentation, and you have to buy all their nonsense (e.g., Eclipse based IDEs) to use it.
JBOSS isn't bad, but only because the price difference is so strongly in its favor.
I'd rather recommend Spring, Tomcat and ActiveMQ as an excellent alternative. If EJBs are absolutely required, add OpenEJB to that mix.
2018 update: My affection for Java EE as a standard and its app server implementations has cooled in the last nine years. I think a better answer is to go with Spring Boot. Deploy an executable JAR on a JVM and never worry about a Java EE app server again.
I'm saddened by Oracle's purchase. I
think that the talent has leaked away,
and Oracle has no clear idea of what
they want to do with WebLogic. They've
been stuck on version 10.1 for a few
years now.
There are a couple of problems with the above comment. First, Oracle only purchased BEA 1.5 years ago, and even then that wasn't a DOJ approved transaction. The final sale was not approved until something like 12 months ago.
Secondly, Oracle has made three releases of WebLogic since acquisition. They are now on version 10.3.1 (or "11g").
Lastly, I think Oracle is - surprised to say that I am - moving in a clear direction. With the recent acquisition of Sun, Oracle is now the primary provider of Java technology and has what many consider to be the leading Java application server. They would not have invested in these companies and technologies without a clear plan to dominate the market. I think Oracle's recent movements in the Java EE 6, WebLogic, and JDeveloper spaces show that they are pushing extremely hard to become the Java leader.
I'd still prefer JBoss; it's simple and just works. I'm having loads of problems converting a Seam 2.x app from JBoss to Weblogic, but I'm hopeful that I will be successful at some point.
Personally I would choose JBoss (community version) over Weblogic (Server) because it's free (you know, like in freedom). But that isn't answering the question, so...
I can see two main reasons for choosing Weblogic:
Weblogic is a well integrated product with a single configuration mechanism/file (easier* to configure and maintain).
Integration with Tuxedo.
*) The term easier is subjective. Most things are easy when you know how to do them.
I've done 3 evaluations of WebLogic, JBoss, and WebSphere. WebLogic won every one of them, hands down. Having said that, my simplistic guidance is this: use JBoss if you are NOT worried about scaling past several thousand concurrent users. However, if you intend to scale beyond that, you're going to need something with proven horsepower and robustness - that's WebLogic.
Note: app server vendors generally sacrifice technical features for stability. In other words, robustness is in dynamic tension with technical features. If you want new features, you get more bugs along with it. It surprises me how many technicians don't get that. But, if you think about why you don't rush out and buy the first new Windows OS version when it comes out, you'll understand perfectly why this is so.
HTH
I had worked on jboss for a year and on weblogic for more than a year now, my experience with the web logic is good compared to jboss as weblogic is more stable and robust, it can handle more than 3000 concurrent requests without throwing a single exception where jboss failed to do so and admin console for the weblogic is excellent, but I think weblogic is more complex then jboss. As far as client is investing money on application server, my choice will be weblogic for sure.
Well, i'd recommend using Spring+Tomcat and would introduce a full-blown JavaEE Application server only if i absolutely have to.
regarding Weblogic and JBoss, i'd prefer JBoss as Weblogic is more complex.
I developed Java based application for JBoss 4.x and 5.x for two years. After that i had to work with Weblogic 11. It wasn't easy to change my mind but now i think, WL much better. More stable, faster and the Admin Console...like a dream..very easy to do settings and monitoring.
So, my choice is Weblogic.
I would think you guys should consider TC Server, its a variant of Tomcat from Vmware. Might be good in an enterprise environment, since most of them should be able to work it out, as part of there virtualization deals.
http://www.vmware.com/products/vfabric-tcserver/
PS - I have used WLS extensively. For some applications it might be good. For some you really do not need it. So its very much driven by use case, scale etc.
You need to consider the TCO Total Cost of Ownership
You must take into account these costs when using JBoss:
Annual support subscriptions
Higher on-going management and administration costs
Impact of outages on cost
Impact of product’s performance on cost
Higher cost for interoperability testing and integration of the disparate OSS projects
Complexity and cost of supporting an integrated OSS solution
Insurance policy for indemnity protection
Cost to support and maintain modified code
Extra time and effort to deal with a myriad of open source licenses
JBoss (Red Hat) has yet to release a commercially supported 100% Java EE 5-compliant container*. There is a beta of JBoss 5 out. Hopefully they won't be 3 years behind for Java EE 6.
JBoss is more concerned with their microcontainer than Java EE x because that's what they say their customers are more interested in. I have never met any of those customers. But it does mean that Java EE is a second-class citizen in their world. As proof, their containers don't even ship in compliant mode; you have to tweak some config files to make it spec-compliant.
If Sun wasn't about to be consumed by the blackhole that is Oracle, I would recommend Glassfish.
Red Hat does have a commercially supported 90% Java EE 5-compliant container. JBoss 4.3 is their "stepping stone" to Java EE 5 version.
It depends.
Do you happen to be in a company who likes to buy support from other companies like "Oracle" and don't really care about the money spending as long they are covered by the manufacturer ( Yes, I know Redhat sells the support also but some companies don't like to buy from them )
Anyway , this is a rather subjective question, I don't think there would be a correct answer.
IBM released their BETA version of Java EE 6 server. So in case of Java EE 6 I think IBM would be the leader. Also JBoss is a good server but under heavy loads my experience shows it's not fully reliable compared to WebLogic and WebSphere.
Related
Ive heard bits and pieces about Seam and Weld in Java 7, and am trying to figure out how they relate to Spring. Any pointers to good references appreciated.
Spring might some day become obsolete for new projects. Still, in the last X years almost every Java EE project was done with atleast a bit of Spring technology (in my experience), so there is a lot of software out there running Spring ( I am currently on a project which uses Spring 2 ) and that isn't going to change in the near future. Corporation don't change a running system just because the new Y technology is out. (As all the COBOL software laying around painfully demonstrates)
So to directly awnser your question, I believe that Spring knowledge will remain a must for many years to come.
No. As others have said Spring is more than DI and is established.
The reality is there are three entities competing (and in some cases working together) for more users/developers.
VMware aka Springsource
Redhat aka JBoss, Seam and Weld
Oracle aka Glassfish
I would like to believe that each one of these companies doesn't have an agenda but the reality is they do and they want you to use their technology. You'll often see developers (employees) of each project vehemently trash the other project. Avoid this and make your own opinion by trying each.
Spring is much more than dependency injection, although DI is at its core and many people receive no more of it.
I worked with both Seam and Spring and found a surprising number of things possible in one, but not the other. They do not cover entirely the same area. Where they do, they are both viable alternatives. Spring is actively maintained. I cannot see it die anytime soon. That was the answer to your question heading.
To address the body of your question: Sorry. I’d be interested in a succinct but in-depth comparison as well.
Using Getting back up to speed on Java after 8-10 years as a starting point...
Along with updating myself with the core JDK6 features, would knowing the different components of JBoss be enough of a refresher?
Though I have about six+ years of Java development experience, it's been about five years since I've done professional Java coding.
I used to do a fair bit of work with WebLogic, but as noted earlier it's been five years...
The best "refresher" I've always found when working with a technology I haven't used in a while is to actually try to do some sort of project with it. Reading is great, but actually building something useful is even better.
I'd start by doing the following:
Download a recent version of JBoss from here.
Study the documentation, found here, chapter 12 has a lot of good info for actual application development.
Try building a simple web application using servlets, JSP's and session beans.
As far as whether "knowing the different components of JBoss be enough of a refresher to make you marketable", that depends on who's hiring. If they are looking for someone who already knows these technologies well and can hit the ground running, then probably not. But if you can find a company that judges you based on your attitude/aptitude and willingness to learn, then you may have a shot.
It's always better to have experience, but if someone is driven to learn then they'll almost always overtake the experienced person who does nothing to keep learning and keep their skills sharp. The hard part is finding a company that hires on that basis, because sadly, it's often not the case.
Good luck!
I'd like to upgrade from Java 5 to Java 6.
We all know about the technical advantages and benefits, but:
I have the problem that a major client refuses to upgrade from java 5 to java 6 because of "the risks" and "no/too few benefits for us" (banking sector).
What can be answered to a non-technical decider at the client what benefits he'll get from an upgrade - or otherwise which problems/consequences may arise if he'll stay with java 5?
It's not a "fire and forget"-product, it's activly extended with new functionality/features - the development is and will be constantly going on - the dev team would definitly benefit from the jdk 6 features/tools.
EDIT: The reached EOL of Java 5 is a valid point indeed, but it doesn't convince the client because he is using the IBM JRE/JDK 5, which seems that it has not reached its end of life yet. And, beside that the client stated:
"Java 5 is running fine for years and its unlikely that new, unseen problems arise"
Java 5 is now well past its end-of-life date. Sun/Oracle will no longer issue public updates to it.
Java SE 5.0 is in its Java Technology
End of Life (EOL) transition period.
The EOL transition period began April
8th, 2007 and will complete October
8th, 2009, when Java SE 5.0 will have
reached its End of Service Life
(EOSL).
If you find a bug in Java5 now (e.g. a hotspot crash - they do happen), you're screwed. If you have a dedicated support contract with Sun/Oracle, which they do offer for those stuck on obsolete versions, then they can fix it for you.
You could argue that the risk of staying on an unsupported platform is greater than the (more manageable) risk of migrating.
Over time, the client will increasingly need to upgrade because of things like:
Java 5 not being supported on some new hardware or operating system platform,
poor performance relative to newer Java releases,
greater coding and testing costs relative to newer Java releases; e.g. due to the "clunkiness" of older APIs, not being able to use streams, etc
increasing cost of vendor support1: you have to pay for support to get security patches, and the older the release the more you pay (I think)
difficulty of retaining Java developers to work on Java 5 projects,
third party Java libraries no longer being developed and supported for Java 5,
compliance issues; e.g. https://stackoverflow.com/a/3434063/139985
and so on.
But the longer the client delays upgrading, the larger the Java version jump involved, and more work (and potentially pain) that will be involved.
And the longer the client delays, the larger the accumulated costs of things like hardware provisioning, developer costs, deferred projects and so on.
To illustrate, suppose that you had waited 10 years to upgrade from Java 1.1 to Java 1.2. That would mean that you would have spent extra 10 years developing applications that used Hashtable and Vector as their primary data structures. And when you finally upgraded you would have 10 years worth of additional "legacy" code that is more difficult to maintain than if it had been written using Java 1.2 collections.
But the bottom line is that if the client insists on staying an old version of Java, you need to either go along with their wishes (and make sure that you pass on the extra costs!), or find a way to exit your contractual relationships with the client.
1 - The End of Life / End of Service dates vary from one vendor to the next, but AFAIK all major vendors have EOL'd Java 5 by now. Indeed Oracle have EOL's Java 6 and Java 7 as well.
From the source:
Q: How is Java SE 6 different from
the previous version (J2SE 5.0): what
are the improved and updated areas,
such as functionality, security,
performance?
A: Anyone who has existing Java
applications, will benefit immediately
from the performance, reliability, and
UI improvements in Java SE 6. Coupled
with the expanded monitoring and
diagnositics capacities built into the
platform, the release delivers
dramatic out-of-the-box benefits
without any coding changes or even a
re-compile necessary. Simply running
existing Java applications on this
latest release is all that is needed.
More on the same matter (may be of help to elaborate more to the client):
Top 10 Reasons to Upgrade to Java 6
Why should I upgrade to Java 6?
Rather than convince him that there are no risks, I would suggest instead working with him to come up with a risk mitigation strategy.
In other words, agreeing that if you can show that the system running under Java 6 passes tests X, Y and Z he'll be happy to upgrade.
Staff recruitment/retention becomes an issue if the application is seen to be old fashioned. Developers do not usually want to stick around if they see no progression.
Just tell him that's it's a minor upgrade: show him that the version goes from 1.5 to 1.6 using the "-version" command. :)
Since you seem to be aware of all obvious benefits of java 6, and the client has good reason to be conservative, all that's left is to stress that not switching to java 6 will hamper development.
Development will be slower because you will undoubtedly spend time on implementing functionality you get for free in newer releases. And perhaps worst of all, not upgrading on a regular basis makes an upgrade more painful as time goes by, up to the point where it becomes practically impossible.
Typically, overdue upgrades result in a highly unpredictable scenario, with a resulting production loss across the entire company over a longish period of time. (assuming the software impacts a large enough user base within the company)
We upgraded from 1.4 to 1.6 last year. It's been a tremendous help for development, but not without its hiccups. While this was not our motivation, today we are required to "keep up to date" by PCI (credit card handling requirements). Your app may be running smoothly, but I'm sure that Java 1.5 has some security holes that have been fixed since in 1.6.
In Short Java 6 is more optimized,better performance ,reliable and currently supported. It also provides advance options like diagnostics, debugging etc.
Most of Java based technology are already migrated or migrating to Java 6. Even they would stop support for earlier versions.
I'm going to answer from the point of view of the client.
Our systems development shop is still using Java 5. To migrate to Jave 6, we have to test our entire portfolio.
When we moved from Java 4 to Java 5, the process took 6 months, and involved some code changes (mostly changing enum variable names to enumerate).
At this time, our systems development shop has decided that the benefits of Java 6 are not worth the migration pain,
Your bank client feels the same way. They will not migrate until they are forced to migrate to Java 6.
We've had this problem with a client last year and we stood firm and said that future development (against Java 1.4 as it happens) would at a minimum be significantly more expensive in the future and as time went on we it may no longer even be possible with us. It was a risk but we felt it was worth it as it allowed us to greatly reduce our development costs. Obviously we weren't as blunt as the opening line makes out. We showed the client all the reasons why it would get progessively more expensive to stay as they were.
It seems that JINI is pretty much an abandoned project. The latest release from the Jini.org site is from last year, and there has been no news since then.
JINI appears to be very useful to provide services in a completely distributed minor. What happened to this technology? Also what has replaced this technology?
The thread that I linked to claims that web services have replaced this technology. However, web services are strictly a client and server setup, not meant for dynamic distribution for jobs. [It can but it doesn't have the framework to do this] I find it difficult to believe that this technology just disappeared due to a lack of need.
Jini didn't fail due to a lack of need. There were problems with:
oppressive licensing when it was first released
all-Java solution based on RMI
complexity
By the time the licensing was sorted out it was too late. The moment had passed.
It's a brilliant idea, and Bill Joy's a genius, but like a lot of great technologies it simply didn't catch on. The marketplace didn't adopt it.
Jini didn't disappear. As you've noted, it's still available. The adoption rate hasn't been high because it isn't scratching anybody's itch.
From what I see the last Jini release actually was in October 2005 (Check here). What you maybe referring to is the news entry for the Rio project on the jini.org site I guess.
The wikipedia page on Jini tells us
Originally developed by Sun,
responsibility for Jini is being
transferred to Apache under the
project name "River"
The latest release for Apache River (2.2.1) is from last year. There still seems to be some activity on the svn repository. So maybe not completely dead but also not very much alive too.
Web services becoming synonymous with SOA killed the buzz for Jini. Although Jini probably was a better fit for distributed computing as well as SOA at a intra-company/enterprise level, web services and the (highly misused) XML integration was pushed by the major software providers, primarily IBM. Of all the derivatives of RMI/Jini, Javaspaces seems to have survived somewhat. Rio was certainly a early version of Cloud computing, especially when it came to dynamic provisioning. I even wonder what happened to the promise of JXTA and its co-existence with Jini.
I guess radio killed the TV star in this case :(
I believe that this technology just disappeared due to a lack of need. On the simple end, web services take care of distributed needs. On the high performance end, clustering and networking with lower overhead takes care of most needs.
Everyone I talk to who knows (knew) about it claims it was the greatest thing since sliced bread. Why did it fail? Or, if it didn't fail, who's using it now?
Check out GigaSpaces. It's a quite successful Jini/Javaspaces implementation.
I think Jini has a great model, but it is stuck with Java. Web-services is more appealing because it works with standarized protocols, even though Jini service discovery is more natural.
Things have definitely quited down for the idea. Which is strange since you'd think its goals are even more relevant now.
http://www.jini.org/wiki/Category:News
old question, but JINI was given to Apache and became Apache River project. However, that project is now retired.
Zeroconf and other discovery protocols are similarly referred to as the greatest thing since sliced bread; it's just that the flavor keeps changing.
My two cents... Jini was/is nice, but I think it tried to be a Java-centric CORBA back in the day when corporations were beginning to be reluctant regarding paying the big bucks for what CORBA brought to the table. WS-* specs began to acquire the "accepted-solution" mind-share in the industry. I think there was a small window where Jini could have grabbed substantial market share, but it never happened. Sun wanted too much money for what Jini brought to the table compared to other alternatives. I would love to hear from folks that disagree! My opinion is that Jini is sound tech, but business-wise has no future in the enterprise. It may find a niche elsewhere, depending on what Oracle decides to do with it.
Jini was an amazing technology. The only reason pushed EJB systems was that it allowed Sun to sell more hardware as EJB ran best on highpowered machines (due to shared state and database access). At the time (1999) Jini allowed much better scalability which ran well on commodity hardware, so it made sense for Sun to not promote Jini. Its a shame as I kept wondering when someone would release an Open Source easy to use Jini server like JBoss did with J2EE. I did however save companies alot of time and money by using the Jini techniques (based on Linda TupleSpaces) and applying them to writing software systems by using Tuple Spaces implemented in other ways.
The jewel in the crown of Jini was it's JavaSpaces service IMO. Sad that Sun seem to have abandoned it. It still exists as Apache River, but is now retired.