Slashdot Mirror
Open Source Winning Java Server Market
Seldo writes "C|net is reporting that free open-source J2EE servers are gaining market share. From the article: "Analysts say it's difficult to measure the extent to which open-source Java application servers, such as Tomcat and JBoss, have eaten into the revenue of commercial providers of Java application servers. But the growing popularity of the open-source application servers is undeniable." The article also points out that the emergence of J2EE as a standard led to a commoditization of Java-based application servers, giving the low-cost OSS alternatives an advantage."
just doesn't do the job right, at least it doesn't work well with database sessions. More than once it locks up database session when the corresponding http session ended prematurely. Sometime it returns errorous status when the database session closes its connection, the http session just died, while it should not. Well enough rant. :(
> How are they stored, anyway? in an enum? or some sort of array? I suppose they only store the most recent moderation done to a comment, as an enum, and then the score as a byte or something. How hard would it actually be to add a moderation option? hmmm, I hear this slashcode thing might be able to give you some insight (no pun intended) on that issue
I touch computers in naughty places
I'd like to see you explain in more detail as well. Do you take issue with the J2EE spec itself or the current implmentations of the spec? If it is such crap, how do you explain its popularity? And who are these cooks that you speak of?
popular == good? mmmkay. it's the spec that's crap. some implementations have tried heroically to overcome it.
Second of all, let's try this again. What about the spec is crap? Can you give some examples? Your argument of "J2EE is crap" really isn't convincing me or anybody who reads this Slashdot that J2EE is an inferior technology. Mmmmkay?
spent too much time on the j2ee crapper lately? a little sensitive? insulting my coding sk1llz? I don't care to convince you or anyone else. the train has left the station packed with the zealots, the uninformed and the coerced (mmm, maybe a theme for this time of year).
this is just me walking away from the debacle and lamenting the waste.
> Java servers feel the open-source heat
.Net or Windows, so Java servers are not being threatened because Tomcat/JBoss alike are getting huge popularity.
I don't get this. Why are commercial software vendors being threatened? MS doesn't care because they don't care about Java. IBM? Maybe, maybe not. WebSphere is really about the whole package not each component. Tomcat is a component. JBoss is a component, so probably IBM doesn't care, either. Sun? They are thrilled to hear news like this. I don't know if Tomcat/JBoss would lead to Sun sales increase, but as far as Sun is concerned, this is exactly what Sun wants to happen. Tomcat/JBoss, Java is getting as widely adapted as ever and... eventually, they'll go to Sun, the creator and the master of Java, right? They may not be selling iPlanet, but they don't care.
Strategy behind Java is very different from that of
Comparing the market for OS Java application servers to the rise on Linux - that has got to be a positive thing for Java in general. Right?
The J2EE market has until recently been a bit like the Unix market 20-30 years ago. Relatively portable and aimed at businesses.. with big money to be made.....and then there was Jboss
There are a few more open-source J2EE app servers than just Jboss and Tomcat - and its good that these are targeting different markets (just like the various Linux Distributions target different types of user/server markets )
Yeah! Companies are really starting to understand the value of open-source (free speech) software. This GetThere guy is really saying you can take you proprietary code and shove it where the SUNW don't shine.
Will the companies that sell J2EE app servers today be in some sort of trouble if J2EE becomes a commodity? No, they're not in trouble at all because they make money from their unique products and services around J2EE. Oracle make money from their databases, for IBM and Sun its hardware + services. Macromedia sell J2EE as a backend to a Flash/swt gui builder kit(yuck! but hey different strokes to move the world i guess) . BEA well... er.. yeah they are in a world of shit probably! (but BEA can adapt and focus on their performance centric niche market).
J2EE was always intended to be a commodity thats why the big guns adopted it because they understood the importance of customer demand for inter-operation and portability. The fact that there are various OS implementations simply proves commodity status has been achieved. I reckon Jboss & tomcat will do for Java adoption in business what Linux did for the Unix market. The big vendors will adapt, costs will fall, and one-hell-of-a-lot more people will finally know what 'Container Managed Persistence' is.
'Be the change you want to see in the world' - Al Gore
I'm with you on the too many cooks point but spare XML. XML 1.0 is a nice, small refactoring of SGML done by a small group of intelligent people. It was designed with respect for the 80/20 rule.
On the other hand, many xml-related technologies (XML Schema, XQuery, XLink, XPointer . . with XSLT and XPath as notable exceptions IMO) are bloated junk designed by huge committees trying to be everything to everyone.
How about this? Just give us one, just one, example of what "J2EE is crap".
oh my fucking god! that's so funny!
Free yourself from J2EE:
Avalon Project: (a well thought out framework for server development)
Phoenix Server Microkernel: (a very good implementation of the avalon framework)
Enterprise Object Broker: (allows publication of any java class as a "bean" without having to conform to Enterprise Bean Spec, with hairthin differentiation between local and remote object invocation)
I myself have always believed that server software development has always been unnecessarily complex. If you like actually being able to simply, freely, quickly create a server app, then these products are for you.
Occam's razor is the blind faith in the natural selection of least resistance and in universal oversimplification. -- EF
Oh yeah, and the avalon project also comes with a growing (and already available) supply of opensource reusable components for: pooling, thread management, etc. Pretty nice. I never gave j2ee another look after I found this project. Also, james, the apache java mail server, runs off the phoenix microkernel. So you know it has to be stable.
Occam's razor is the blind faith in the natural selection of least resistance and in universal oversimplification. -- EF
I'm not sure the root of this thread really was a troll. I think he/she was stating his/her opinion. J2EE is not perfect, and is tremendously complex. After all, it addresses a very complex problem--distributed, reliable, scalable multi-tier computing.
.Net. There's a lot in .Net to be liked if you don't get caught up in the religious battles. And that's coming from a Java guy.
However, if you're looking for a problem with the J2EE spec, look no further than entity EJBs. These things are seriously screwed up, and scream of an implementation based upon a poorly designed predecessor (CORBA) that was rushed out the door. By comparison, JDO really does things right.
As for Java's popularity, I think it really comes down to competition. When J2EE was first released, it really didn't have any competition. Even today, no Microsoft solution really matches up to J2EE in terms of availability (many J2EE implementations already exist), features, and scalability. That said, don't discount
--Be human.
And the alternative? That these providers would have eaten into the pockets of all the companies that chose free open source solutions? Anybody remember how freakishly expensive first application servers were?
I don't think they get the point. Software is not there to make software companies rich. It's there to make all the other companies productive and rich.
"If anything can go wrong, it will." - Murphy
If it is such crap, how do you explain its popularity?
and NT?
Sure. But not with this stuff you're offering. Let's see... Phoenix requires you to restart the server each time I deploy a new 'block' to the server? Uh-huh, so where are the HA features? How do I service my customers while that server is being kicked down? Where is the clustering for HA? How about fail-over?
One obvious and glaring omission in all of the overviews is the lack of basic notion of transaction handling in these frameworks. So I have my blocks deployed and I need to make sure that my block A and block B are working nicely together, committing their changes in an atomic fashion. So how do I enlist these different blocks within the same transaction? Surely you don't suggest I manage my transactions myself in the code and write my own logic for things like transaction context passing? How is transaction demarcation handled within these 'blocks'?
Why do you think people use J2EE?
If you like actually being able to simply, freely, quickly create a server app
It looks neither simple or quick to me. Looks like some very basic features have been omitted that are available on all J2EE applications servers. Writing log components, deployers or rmi code doesn't really require all that much. And the hard parts they just decided to ignore as 'unnecessary'.
J2EE has it's disadvantages and here is an explation why (i.e. your post) is not a troll.
I agree with you totally. Anyone with any experience with J2EE (i.e. not the original poster), has struggled tremendously with entity beans. I have been following JDO closely and like what I see as well. Unfortunately, I haven't had much time to play some of the implementaions out there. The fact is that most projects don't require the overhead and complexity of EJBs and JDO would provide a much better solution for persistance. This ist actually is a very nice feature of the J2EE spec as it doesn't tightly couple EJBs with your web tier.
Well, first of all Avalon is a framework for a server microkernel. It is a generalized framework for any kind of server not app servers in particular. The aforementioned enterpriseobjectbroker is the application server container.
Sure. But not with this stuff you're offering. Let's see... Phoenix requires you to restart the server each time I deploy a new 'block' to the server? Uh-huh, so where are the HA features? How do I service my customers while that server is being kicked down? Where is the clustering for HA? How about fail-over?
It is in the works. Even jBoss started somewhere, but at least this project does not offer a facade of a free sofware project. Hiding their documentation from potential users who don't wish to spend money on the project. Soon, it will support hot deployment, as well as being cluster capable (depending on configuration, all this really requires are a few changes to the AltRMI library). Until then, well if you really require 24/7 uptime, don't use it. Its not ready for that, yet. It is still a relatively young product.
One obvious and glaring omission in all of the overviews is the lack of basic notion of transaction handling in these frameworks. So I have my blocks deployed and I need to make sure that my block A and block B are working nicely together, committing their changes in an atomic fashion. So how do I enlist these different blocks within the same transaction? Surely you don't suggest I manage my transactions myself in the code and write my own logic for things like transaction context passing? How is transaction demarcation handled within these 'blocks'
I found transaction management to be a moot point. You can handle transactions using any kind of transaction manager you wish. As long as you are consistent across your system, then you should have no problems getting a suitable system in place, with as much transparency as EJB Entity beans provide, and possibly more.
My biggest gripe with J2EE is the fact that they have you implement often times unneeded code. Their system is very rigid. Their code looks unruly and is often times redundant. This framework uses logical interfaces which takes seperation of concerns to the next level, and it doesn't force you to implement anything. It gives you complete freedom in how you implement your systems, and it doesn't have the audacity to claim to know a kill all for data storage and retreival interfaces (aka EJB-QL and CMP). The framework doesn't look perfect, but at least you are not shunned for not using their provided interfaces. J2EE is a model where you are reuired to accept the entire "all encompassing" system. I don't believe Sun has all the answers. Avalon assumes a common server framework. I can build on that.
Occam's razor is the blind faith in the natural selection of least resistance and in universal oversimplification. -- EF
what you say isn't true of XML. If you are complaining about the mess of XML based markup lang,uages... that's the point of XML, to support development of markup-languages, those are applications of XML to various domains... and they are not a part of XML itself any more than MS Word is a part of C++ (in which it is written).
-pyrrho
>Maybe you think J2EE is crap because you don't know how to program in Java.
yeah, because that's why the Java programmers think C++ is crap.