- Cause the server to startup more slowly?
- Cause the server to use more memory?
- Wastes a lot of HDD space?
- Consumes more CPU cycles, making the overall product slower?
- Severely increases the time to download and/or install the product?
Lots of folks complaints about all of the above :)
I'm sure they do, but will removing EJB2 support or CORBA support improve any of that? Glassfish V3 for example supports all of that, yet starts up in mere seconds. There also doesn't seem to be any significance difference in memory usage between having CORBA support enabled or not, at least I couldn't measure any on my workstation (with 4GB RAM and 2GB allocated to JBoss AS).
I think I've already been through the HDD space. From the top of my head, Tomcat is somewhere around the 10MB, while Glassfish and JBoss AS are roughly 10x that size (between the 60 and 120MB or so). But does this matter to me? My workstation has a 2TB HDD. What percentage of my HDD do I save by going from Glassfish or JBoss AS to Tomcat? You do the math ;) And how much space would we save for a typical web profile implementation compared to a full implementation? Is that 25MB vs 60MB? Are we really talking about a mere 35MB of HDD space in this time and age? My 3 cents cheap wrist watch has double that memory nowadays ;)
I'm also very curious if you perhaps think that a web profile version of Java EE executes faster, inferring that the mere presence of EJB2 support somehow eats away processor cycles even when not being used. We have done extensive profiling for our app (high volume transaction processing) and I have found absolutely no evidence that EJB2 is somewhere there being alive and secretly consuming our CPU. If you have some evidence that this is happening in say JBoss AS, I would absolutely love to see that evidence.
The final point on my list is basically the same kind of argument as the HDD space one. Does downloading 25MB compared to say 65MB make a real significant difference? With our modern 1MB/s broadband lines this amounts to an approximately 35 second longer wait. How often do you download a new AS? Once a week? Once a month?
The Web profile is a real and significant addition to Java EE 6, but I'm not really sure it was created to alleviate any of the things in my list of suggested items. If we look at your additional items:
Relief from complicated configuration issues,
In what way does the web profile help here? If I don't wish to use EJB2 or CORBA, there is absolutely nothing I need to configure for them. That's pretty much the idea of 'not using it'.
Decrease development time, (start/stop, deploy/undeploy)
As I've explained before, Glassfish V3 has support for the full Java EE stack, yet it starts up in mere seconds. Clearly an application server can start up very fast even though it supports things outside the web profile.
Cloud deployment,
I'm not sure if we're still talking about the same things here. If I'm not mistaken we're talking about what benefits a web profile implementation brings to the user compared to a full implementation right? Apart from the fact that just throwing around the buzzword "cloud deployment" is a little awkward, you seem to forget that with a full implementation I can still code against the web profile standard. A full implementation, by definition, supports the web profile fully
Now if your argument is that a cloud implementation of Java EE might support the web profile sooner than it supports a full Java EE implementation (if ever), then this might be true. But this advantage is for people (vendors) building such a cloud implementation. It's a general advantage of the existence of a web profile and NOT an advantage of using a specific web profile implementation that is actually a subset of an existing full implementation.
Do you understand this? This is really, again, the point I made earlier. The web profile makes it easier for people (vendors) to implement a specific kind of Java EE compliant server, so someone can actually go ahead a build a 'cloud version of Java EE' without the immense bulk of work that a full 'cloud version of Java EE' would require. It's an advantage for people BUILDING Java EE implementations, not necessarily for people USING Java EE implementations.
Remove unused libraries
This by itself is, I'm sorry to say, a non-argument. It's the same as saying Java EE is heavy, and then explaining it's heavy because it's heavy. The question again is, WHY would users like to remove unused libraries? Is this because they eat away their HDD space? Because they consume CPU cycles? It's the same argument as just saying that Java EE is heavy. Unused libraries typically don't do any of that. They just sit there... being unused... doing nothing...
Have you ever taken a look at how much 'unused libraries' your typical Linux distribution installs? (or Windows, it that's your poison) There are FAR, FAR, FAR more of them and together they weigh in at FAR more MB or even GB than is the difference between your "web profile" implementation and a full implementation of Java EE.
If people were so concerned about "unused libraries", then tell me, why doesn't anyone trim the server on which their Java EE AS runs? This will yield far more disk space (easily in the hundreds of MB range, with a little determination even in the lower GB range for some distributions). And does anyone do that? Does anyone really bother with it? (apart from the really obvious things like not installing desktop stuff like X and Open Office on a server of course)
Best of all, if you're really worried about this stuff, then at least JBoss AS and Glassfish let you remove unused stuff already. Just for the fun of it, I did so in the past, but my applications did not run any faster ;)
If all you are really planning to do is to deliver a subset of Geronimo anyway, why not do exactly that and just offer an already pruned down to Java EE web profile version of Geronimo? Although I would be surprised if it would bring any of the benefits you seem to think it brings (faster startup, faster execution, less memory, easier configuration), I'm sure there would be some market for it. Join the Geronimo team and have this as a download on the regular Geronimo download page.
Finally, I want to make clear I'm not some sort of anti-web profile evangelist or so ;) I greatly applaud efforts like Resin 4 that supports the Web Profile and can now be an official Java EE 6 product, where otherwise (without the existence of the web profile) it probably wouldn't have been.
I'm just skeptical about creating a new product, solely build out of parts from an existing Java EE implementation, especially when such implementation itself will most likely also simply support the web profile itself.
