Richard Davies wrote: The UK has a good crop of technology pioneers in cloud computing - for example ElasticHosts, FlexiScale, Flexiant, OnApp - and also some strong government initiatives such as G-Cloud.
We will have to see whether this kind of technical leadership converts into swift mass-market adoption or not.
I've been actively involved with Java development in one way or another
since 1996, including working with some of the original issues of the
servlet specification, the early adaptation of the EJB spec, and migration
to JSP not long after it became an official part of the J2EE spec. I
remember when Rick Ross first sent his e-mails for Javalobby on Usenet; I
remember playing with the specs to discover if the grail was to be found in
them as promised.
It hasn't come through for me. That's okay, because technology is and
will always be a moving target; I've refined what the grail is as I've come
near it many times, and I will continue to do so as long as my career is not
completely stagnant. What worries me, though, is the thought that the grail
is actually moving further away as time goes by, instead of staying just out
of reach, like a carrot for a hungry dray horse.
The Java Community Process was supposed to give relevant people in the
Java Community a chance to influence the specifications in positive ways.
It's guaranteed to be an arduous process, and it has lived up to its
billing. What Sun needed to do was guide the expert groups down a path laden
with thorns to determine not only what was best, but how to get what was
best implemented. What it did was let the expert groups descend into a
morass where those who shouted most were heard.
The Enterprise JavaBean specification is a good example of this. EJB 1.0
fell critically short of being easily deployable; EJB 1.1 added some great
features, and 2.0, while fulfilling some of the void left by the 1.1
specification, has sadly started to invalidate EJB's promise. The best
things about EJB remain the same; the new additions, such as local
interfaces, simply add complexity where it's not needed. And that's where
Sun's community process has failed. Nearly every container already had an
implementation of local interfaces before they were added to the spec; they
were added as a sop to a few major players who simply hadn't kept up with
the "smaller" containers. Obviously, it was possible to do without a lot of
overhead, yet Sun felt it was all right to make not only every container but
every EJB coder work with extra interfaces as well as a separate use model.
This is the JCP breaking down; instead of making life simpler, it made it
harder and didn't actually finalize the most crucial areas left in the
entity bean section of the specification, such as finalizing the managed
relationships.
The 1.4 API's logging model is another example of this: taken nearly
verbatim from Log4J, it's a floodgate-based model, where each category can
be set up individually, and as messages rise above a deployer-specified
"message level," they become visible in the output stream. This is nice,
certainly nicer than System.out.println() strewn throughout code, but the
introduction into the 1.4 API would have been the perfect time to present
something more powerful by default, such as a bitmasked logger, where you
would be able to say you wanted to see all "startup," "info," and "fatal"
events in a given category, and in another you wanted to see only "startup"
and "shutdown" events. Instead, Sun continued to take the easy way out,
repackaging Log4J according to various contributors in the expert group and
letting it go.
I would have liked to see Sun actually leverage the expertise of the
Java community it could spend time developing the language and application
interfaces while accepting the contributions of programmers who could
improve the core implementations. That would yield massive benefits: a
best-of-breed would appear in the language API and application developers
would feel empowered and more invested in Java. A best-of-breed would
probably have prevented things such as local interfaces (which actually do
have a beneficial performance impact, just not enough of one to justify
their cost), and allowed a more open discussion of other relevant APIs.
As Sun continues to allow the JCP to run wild, contributing APIs that
don't actually improve the usage patterns of the language, Java will grow
more and more irrelevant, until the weight of the poor APIs drags it into
oblivion. Sun needs to listen to its own best practices groups, and
eliminate the cruft introduced by users who very competently implement
things that run counter to the mindset that made Java the useful tool it is
today.
About Joseph Ottinger I am a software evangelist for GigaSpaces technologies, as well as a writer and musician. I've been the editor-in-chief of Java Developer's Journal and TheServerSide.
GigaSpaces Technologies is a leading provider of a new generation of application platforms for Java and .Net environments that offer an alternative to traditional application-servers. The company's eXtreme Application Platform (XAP) is a high-end application server, designed to meet the most demanding business requirements in a cost-effective manner. It is the only product that provides a complete middleware solution on a single, scalable platform. XAP is trusted by Fortune 100 companies, which leverage it as a strategic solution that enhances efficiency and agility across the IT organization.
Reader Feedback: Page 1 of 1
#12
Andy Paul commented on 9 Dec 2002
There are many good things in J2EE (think of servlets, JDBC etc.), but EJB is one of the worst technology I have seen in years. This does not stop project managers to use EJB and either fail to complete the project, or produce crap.
#11
Viraf Karai commented on 7 Dec 2002
Sun has provided the JCP to allow best-of-breed
ideas to be used in future editions. Admittedly,
EJB is pretty controversial (I haven't used it)
based on the fact that so many people have so
much to say about it.
Let's look at so many of the successes that Java
has tasted. BEA, WebSphere, and JBoss have become
household names. Java has forced Microsoft to
start thinking for a change. Can you imagine a
world with everyone using just Windows and .net.
Jeeze, I might as well hang up my hat and start
peddling real estate.
If the JCP is really painful to work with, then
let's try and change it to be less bureaucratic
and more democratic. Sun has given a lot to the
Java community. I think it's time for us to return
the favor.
By the way I don't work for Sun or any Java vendor. This is just my humble opinion. I'm sick
of people running Java down.
#10
John Bledsoe commented on 5 Dec 2002
Two examples? Out of now 200 specification submissions. Never mind JMX is a complete and utter success in the community. JBoss, Jetty, and Avalon use JMX to provide management features. Even Tomcat is considering requiring it for Tomcat 5.0. How about MIDP and all of the associated APIs? Most people I know have a MIDP phone and apps they've downloaded. If you're using XML, 10 to 1 you're using JAXP. All of these specifications started in the JCP.
It's amazing the JDJ would print this sad and poorly reasoned article. The author failed to provide a convincing aricle when I can disprove him in 10 sentences.
#9
Ceki G commented on 5 Dec 2002
If I am not mistaken, Joseph has already submitted his idea for
bitmasked loggers to the log4j-user mailing list. It was probably
summarily brushed aside because bitmasked loggers (as I understand
them) still rely heavily on levels. (If that was indeed the case, I
apologize.) Let me explain why imho bitmasked loggers are not a good
idea.
The central problem in logging is the proper categorization of logging
statements. Log4j offers two dimensions of categorization: the logger
space and the level space (i.e. the set of levels). Thus, each logging
statement is characterized by two parameters, the logger of the
statement and the level of the statement. For example, when we write:
Logger l = Logger.getLogger("wombat");
l.setLevel(Level.DEBUG);
l.info("Sun is losing its way.");
the logging statement is defined by its logger 'l' and its level 'INFO'. As far as the logger 'l' is concerned the statement is enabled because DEBUG <= INFO.
Bitmasked loggers enhance the logic of logger/level interaction,
instead of integer comparison between levels, we would have bit masked
comparisons and that would allow more possibilities.
However, instead of enriching the logical interactions between loggers
and levels, we could increase the number of dimensions of the logging
space. More dimensions allow for far richer interactions. Surprisingly
those interactions are more tractable as well. The hard part is to
compose the interactions in a way that make sense without being too
costly in computating power. The next version of log4j, i.e. 1.3,
promises to do just that.
By the way, I very much enjoyed the article. I really wish Joseph were
wrong.
EJB and J2EE are bloated and over-complicated...don't worry I don't support .NET (Only brain washed idiots would tie their code into a single operating system!...bring it on M$ drones).
However, I do think that a closely knit open source team could come up with a far better specification for Enterprise development based on Java...A break away from the norm is needed.
I am all for starting up new development where we can write some real fast, tight java code for the enterprise to use...EJB contains WARS, EARS what the hell is all that about? A JAR is a JAR and a java class is a java class lets not complicate it!
#7
CS commented on 6 Nov 2002
EJB and J2EE are bloated and over-complicated...don't worry I don't support .NET (Only brain washed idiots would tie their code into a single operating system!...bring it on M$ drones).
However, I do think that a closely knit open source team could come up with a far better specification for Enterprise development based on Java...A break away from the norm is needed.
I am all for starting up new development where we can write some real fast, tight java code for the enterprise to use...EJB contains WARS, EARS what the hell is all that about? A JAR is a JAR and a java class is a java class lets not complicate it!
#6
El Guapo commented on 5 Nov 2002
All this handwringing over JCP and the direction of Java .. and possibly a bit of that uncomfortable bloat. I fail to see why this bodes well for .NET. At least we're having this discussion. Will the day ever come when the .NET M$ crowd will have angst over a "Community Process"???? Not in my lifetime.
#5
Joseph Ottinger commented on 5 Nov 2002
I'd say that the JCP isn't really open. It wasn't free for a long time (I was one of the first ones I know of to get a waiver for entrance without paying the fee, for example.)
What the JCP really is is driven by the industry, which means that companies who are hardly disinterested sway the JCP their way (see EJB, see logging, see the JSTL). I don't know if open and free would work better, but it's clear to me that what we have now doesn't work very well.
#4
Joe Ottinger commented on 5 Nov 2002
I agree with you, Johnny... why haven't I? Well, let's see: there's a full time job, three kids, a wife, a musical career to tend to, the REST of Opensymphony, at least four other personal projects, sleep, food, time driving to and from work... Yeah, I think I can squeeze five minutes or so a day into designing a new logging API all by myself. :) Designing it wouldn't be hard, but the implementation phase would be fun.
#3
Juan Valdez commented on 5 Nov 2002
Yep, Java is bloating.
#2
Johnny Howard commented on 4 Nov 2002
If the API from Log4J isn't what your idea world would have wanted, then why hasn't anyone written it like you wanted. Who needs a committee to design something practical and useful? Let me answer, no one!
#1
Money Hungry commented on 4 Nov 2002
You mean free and open and driven by the community isn't working.
mmmmm.....
No wonder MS .NET is getting so popular and groups like TMC are down of Java.
Andy Paul wrote: There are many good things in J2EE (think of servlets, JDBC etc.), but EJB is one of the worst technology I have seen in years. This does not stop project managers to use EJB and either fail to complete the project, or produce crap.
Viraf Karai wrote: Sun has provided the JCP to allow best-of-breed
ideas to be used in future editions. Admittedly,
EJB is pretty controversial (I haven't used it)
based on the fact that so many people have so
much to say about it.
Let's look at so many of the successes that Java
has tasted. BEA, WebSphere, and JBoss have become
household names. Java has forced Microsoft to
start thinking for a change. Can you imagine a
world with everyone using just Windows and .net.
Jeeze, I might as well hang up my hat and start
peddling real estate.
If the JCP is really painful to work with, then
let's try and change it to be less bureaucratic
and more democratic. Sun has given a lot to the
Java community. I think it's time for us to return
the favor.
By the way I don't work for Sun or any Java vendor. This is just my humble opinion. I'm sick
of people running Java down.
John Bledsoe wrote: Two examples? Out of now 200 specification submissions. Never mind JMX is a complete and utter success in the community. JBoss, Jetty, and Avalon use JMX to provide management features. Even Tomcat is considering requiring it for Tomcat 5.0. How about MIDP and all of the associated APIs? Most people I know have a MIDP phone and apps they've downloaded. If you're using XML, 10 to 1 you're using JAXP. All of these specifications started in the JCP.
It's amazing the JDJ would print this sad and poorly reasoned article. The author failed to provide a convincing aricle when I can disprove him in 10 sentences.
Ceki G wrote: If I am not mistaken, Joseph has already submitted his idea for
bitmasked loggers to the log4j-user mailing list. It was probably
summarily brushed aside because bitmasked loggers (as I understand
them) still rely heavily on levels. (If that was indeed the case, I
apologize.) Let me explain why imho bitmasked loggers are not a good
idea.
The central problem in logging is the proper categorization of logging
statements. Log4j offers two dimensions of categorization: the logger
space and the level space (i.e. the set of levels). Thus, each logging
statement is characterized by two parameters, the logger of the
statement and the level of the statement. For example, when we write:
Logger l = Logger.getLogger("wombat");
l.setLevel(Level.DEBUG);
l.info("Sun is losing its way.");
the logging statement is defined by its logger 'l' and its level 'INFO'. As far as the logge...
El Guapo wrote: All this handwringing over JCP and the direction of Java .. and possibly a bit of that uncomfortable bloat. I fail to see why this bodes well for .NET. At least we're having this discussion. Will the day ever come when the .NET M$ crowd will have angst over a "Community Process"???? Not in my lifetime.
Joseph Ottinger wrote: I'd say that the JCP isn't really open. It wasn't free for a long time (I was one of the first ones I know of to get a waiver for entrance without paying the fee, for example.)
What the JCP really is is driven by the industry, which means that companies who are hardly disinterested sway the JCP their way (see EJB, see logging, see the JSTL). I don't know if open and free would work better, but it's clear to me that what we have now doesn't work very well.
Joe Ottinger wrote: I agree with you, Johnny... why haven't I? Well, let's see: there's a full time job, three kids, a wife, a musical career to tend to, the REST of Opensymphony, at least four other personal projects, sleep, food, time driving to and from work... Yeah, I think I can squeeze five minutes or so a day into designing a new logging API all by myself. :) Designing it wouldn't be hard, but the implementation phase would be fun.
Johnny Howard wrote: If the API from Log4J isn't what your idea world would have wanted, then why hasn't anyone written it like you wanted. Who needs a committee to design something practical and useful? Let me answer, no one!
Money Hungry wrote: You mean free and open and driven by the community isn't working.
mmmmm.....
No wonder MS .NET is getting so popular and groups like TMC are down of Java.
T
CS wrote: EJB and J2EE are bloated and over-complicated...don't worry I don't support .NET (Only brain washed idiots would tie their code into a single operating system!...bring it on M$ drones).
However, I do think that a closely knit open source team could come up with a far better specification for Enterprise development based on Java...A break away from the norm is needed.
I am all for starting up new development where we can write some real fast, tight java code for the enterprise to use...EJB contains WARS, EARS what the hell is all that about? A JAR is a JAR and a java class is a java class lets not complicate it!
CS wrote: EJB and J2EE are bloated and over-complicated...don't worry I don't support .NET (Only brain washed idiots would tie their code into a single operating system!...bring it on M$ drones).
However, I do think that a closely knit open source team could come up with a far better specification for Enterprise development based on Java...A break away from the norm is needed.
I am all for starting up new development where we can write some real fast, tight java code for the enterprise to use...EJB contains WARS, EARS what the hell is all that about? A JAR is a JAR and a java class is a java class lets not complicate it!
Can you bring services from the cloud to your customers faster and have them adopt it with ease of use or bring the power of bundled services to the fingertips of your clients without creating new rigid ‘apps stove pipes'? Do you want to prevent your business running away to publ...
OCZ Technology Group, a provider of high-performance solid-state drives (SSDs) for computing devices and systems, on Tuesday announced the Z-Drive R4 CloudServ PCI Express (PCIe) flash storage solution, designed to accelerate cloud computing applications and reduce operating expe...
Many organizations have embraced, or are considering, the benefits of cloud computing – speed, flexibility, increased expertise, shared workload, reduced costs, etc. The benefits are many – but so are the risks. What are the threats to cloud security? Which parties assume respons...
In August 2011, SHI Enterprise Solutions (ESS) division launched the SHI Cloud, offering reliable and cost-effective industrial-grade cloud computing platforms. That same division achieved an 82 percent increase in revenue over 2010.
SoftLayer Technologies on Tuesday announced the immediate worldwide availability of SoftLayer Object Storage, a redundant and highly scalable cloud storage service that allows users to easily store, search and retrieve data across the Internet, with optional CDN connectivity, or ...
About Newsfeeds / Video Feeds
.gif)
Can you bring services from the cloud to your customers faster and have them adopt it with ease of use or bring the power of bundled services to the fingertips of your clients without creating new rigid ‘apps stove pipes'? Do you want to prevent your business running away to publ...
OCZ Technology Group, a provider of high-performance solid-state drives (SSDs) for computing devices and systems, on Tuesday announced the Z-Drive R4 CloudServ PCI Express (PCIe) flash storage solution, designed to accelerate cloud computing applications and reduce operating expe...
Many organizations have embraced, or are considering, the benefits of cloud computing – speed, flexibility, increased expertise, shared workload, reduced costs, etc. The benefits are many – but so are the risks. What are the threats to cloud security? Which parties assume respons...
In August 2011, SHI Enterprise Solutions (ESS) division launched the SHI Cloud, offering reliable and cost-effective industrial-grade cloud computing platforms. That same division achieved an 82 percent increase in revenue over 2010.
SoftLayer Technologies on Tuesday announced the immediate worldwide availability of SoftLayer Object Storage, a redundant and highly scalable cloud storage service that allows users to easily store, search and retrieve data across the Internet, with optional CDN connectivity, or ...
