|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 44
Messages: 44
Messages: 44
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Former CTO for Sun's J2EE App Server says J2EE may lose
Peter Yared, former CTO for Sun's application server, says that "Java/J2EE may lose out to Open Source technologies in the future, as IT managers are architects get tired of the time and cost of building in Java," in an interview with Integration Developer News. However, his position may be biased, as he's employed by ActiveGrid, which bases solutions on LAMP, and thus is a bit of a J2EE competitor.
Mr. Yared says that ActiveGrid has the same benefits for users that Ruby on Rails does, with "developers can be 10X faster than J2EE, and that means changes and updates they need to do to their code can be done in much less than the year or 2 it can take today. And, we can make updates 10x less expensive than J2EE because integration and deployment costs are reduced."IDN: How do devs escape from this growing complexity of J2EE and get on the road to composite apps?
Yared: At the end of the day, there is not a single high-level tool for J2EE that is useable or clean. They are all either code generators or generate proprietary metadata, There is nothing that’s clean. So, there is no high level development tool. That means you have people hand coding to these [Java] APIs, and that limits the number of people that can build these kind of new [composite] apps. Discounting the marketing spin from the fact that this is very much a softball interview, Java and J2EE (in particular) has a huge target painted on it - being used as the comparison point for Ruby, .NET, and now LAMP. In advertising, comparisons mean that there's merit in the competitor's product, so perhaps they're complimenting J2EE more than they expect.
On the other hand, the points they often try to make have a certain validity. Do you think the deployment step in J2EE is invalid? One of Mr. Yared's statements in the interview is that "No one at the design point says they want to run on 4 8-way [CPU] servers anymore. It’s expensive, hard to build applications for, and hard to deploy." Is that the case? Speaking as an developer, I've developed applications to run scalably on single-CPU to multicore machines in J2EE with what I considered to be little or no effort; is that unusual?
(Note: this article was originally pointed out to TSS by V Cekvenich. Thank you, Vic!)
|
|
|
Message #182416
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
LAMP maybe, Java hopefully, JEE probably not
I'm not sure that it will be LAMP that wins, it's a strong contender and I have to agree that JEE is a long way from the front.
I still have faith in Java, more along the lines of Spring with MDA and Grid though.
Even the vendors like BEA are starting to see this, it's time Sun saw the light (no pun (with LAMP) intended).
-John-
|
|
|
Message #182419
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
J2EE may lose - NOT REALLY
I'm getting more and more tired of comparisons like that. In fact there is no significant comparison between LAMP and Java/J2EE possible, it seems that Mr. Yared not only changed his employer, he also changed his mind (I don't think his new company would like to hear/read him praising competitiors...).
For sure: un-experienced developers MAY be up to 10 times faster raising a web-app in LAMP than in doing the same thing in Java/J2EE. But people always forget about the first "E" in J2EE - "Enterprise" Edition. It's about to support really HUGE distribted systems. I dunno how often people are choosing J2EE for projects that would better be done NOT with J2EE - because they don't need the features of J2EE in their projects - but they buy the overhead J2EE brings with.
I cannot contradict: building up a small and easy web-app goes really fast using LAMP or something similar. As easy as I have been developing Windows apps with Visual Basic for some years. Oh yeah... you got quite fast, quite nice results. But beware of building a system with those "quick-and-easy" development tools that should live longer than 3 years!
As systems evolve, complexity grows. I would like to see Mr. Yared working on a LAMP software that has been evolving for 10 years... *oh my god* currently I have to maintain an application that has been written in VB6 YEARS AGO. meanwhile it's a huge application, nobody wants to change code because its unpredictable what happens after changing a single line. I can imagine that that is similar in LAMP-based systems.
To be true: Java/J2EE has it's complexities. But used at the right place for the right projects - AND WITH THE RIGHT TOOLS - I'd bet you'll be developing as fast as competitors in LAMP with the benefit of producing much more maintainable code!!!
|
|
|
Message #182421
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
LAMP maybe, Java hopefully, JEE probably not
I'm not sure that it will be LAMP that wins, it's a strong contender and I have to agree that JEE is a long way from the front.I still have faith in Java, more along the lines of Spring with MDA and Grid though.Even the vendors like BEA are starting to see this, it's time Sun saw the light (no pun (with LAMP) intended).-John-
Agreed. I think its time we had a marketing term that stood not for what J2EE 1.4 is today (with all the old horror stories of EJB 2.x, Entity Beans and such like) - but for the new simple lightweight approach to developing in Java while reusing those JEE services you actually want.
Strong contenders seem to be POJO or Spring? Its easy to show LAMP being more lightweight than a traditional JEE development - its much harder when comparing it to modern POJO approaches with Java IDEs and Spring.
James
LogicBlaze
|
|
|
Message #182428
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Not Now...
As far as java is concerned I believe that still a lot of enhancement of API’s happens on daily basis. Apart from that J2ee technologies name any (jdbc,ejb, rmi,jass,etc etc ) is used by almost 75% of the Software development organizations.
Even the vendor specific or opensource Content Management and Portal Server are either on J2ee platform or are being migrated to J2ee platform so to make their product a 100% JSR168 compliant.
I think its not the right time to even think about this…
http://lokeshpant.blogspot.com
|
|
|
Message #182431
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
J2EE may lose - NOT REALLY
I agree completely. Not everything is a "web app" and not everyone in the Java community or in software development cares about "web apps". Frankly, I'm tired of all the whining about J(2)EE - "Its toooo hard!, wah!". Enterprise development shouldn't be done by novices anyway. There are tools and skill sets appropriate for each of a number of software development purposes. Make sure you own skills are appropriate to the task and pick the tools that fit best. If you pick the wrong tools for the task or you lack needed skills, it does not prove J(2)EE or Spring or LAMP or whatever you tried is bad.
That being said, as someone who works in J2EE/JEE, it has been and still is unnecessarily complicated in some ways and incomplete in others. Entity beans are still a bad idea and there are many bad designs and patterns being recommended to JEE developers. Remember when some "experts" encouraged developers to make numerous fine-grained EJBs? They confused business objects with EJBs. JEE and the advice being given have much improved since then and its getting better all the time.
|
|
|
Message #182434
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
J2EE may lose - NOT REALLY
That being said, as someone who works in J2EE/JEE, it has been and still is unnecessarily complicated in some ways and incomplete in others. Entity beans are still a bad idea and there are many bad designs and patterns being recommended to JEE developers. Remember when some "experts" encouraged developers to make numerous fine-grained EJBs?
You can fool some of the people some of the time, but you can't fool all of the people all of the time.
If it can be proved that vendors were aware of EJB problems internaly, but conspiderd... is it racketering? That would be triple dameages, not just the uniform comercial law damages. (PHB's, please... I am not a lawyer, just pissed when software fails, I am not w/ that group; I make sofware work) Some large projects lost lots of money, due to paid "expert" advice and poorly designed software, I would love for them to get wiped w/ a wet noodle! Tarred and featherd for makeing the rest of us look bad. Adventure Builder, ok.
Now... lets all find some good designs and good advisors. JDNC/Groovy works for my large projects, C/S style.
.V
http://roomity.com as usefull example.
|
|
|
Message #182457
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
look for the right reasons...
Some large projects lost lots of money, due to paid "expert" advice and poorly designed software,
you exactly hit the point! the projects didn't fail because of J2EE, it failed because of the usage of wrong tools and missing skills. In most cases projects are definitely not failing because of non-adequate technology, projects fail because of wrong skills, wrong tools and the wrong people!
I didn't want to say that groovy,ruby,lamp and what the heck else projects are not working. What I tried to point out is that the "overhead" a J2EE project produces by the regulations of the standard keeps the whole system more maintainable. This is what I can say from my personal experience. And using the right tools on the right places allows a skilled developer to get a grip on the complexities of J2EE.
For sure, in J2EE/JEE there are many things that we are not very happy with. But as you see J2EE is evolving permanently and the upcoming ejb3 is a step into the right direction.
So please don't blame it on EJB/J2EE - try to look honestly for the real reason why a project hits the wall!
- HANS -
http://hanzz.zapto.org
|
|
|
Message #182461
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Somking could be danferous to your helth
- try to look honestly for the real reason why a project hits the wall!- HANS
Does smokeing lead to cancer?
.V
|
|
|
Message #182469
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Lamp People
I know this is a little bit off topic, but one of the things I find interesting about the LAMP vs Java thing is the people behind it.
I know quite a few Java developers and some LAMP developers. When we talk shop with Java developers the conversations are many times about team building, modeling code, design patterns, when to abstract vs. when not to abstract, and new and interesting API's that we have worked with. Talking with the LAMP guys always seems to be more about the new and coolest hack, some app that they were able to whip out in two days, how they implemented their own version of some API that was already out there, etc. One LAMP developer I know works on a team with 20 other people, but when he talks about work, he talks as if it is every man for himself.
From my personal point of view there seems to be a big difference in the mind sets of LAMP and Java developers. Maybe it makes sense that people of different mindsets would be attracted to different langauges?
One more comment. Peterr Yared says:
"Java/J2EE may lose out to Open Source technologies in the future, as IT managers are architects get tired of the time and cost of building in Java,"
From what I have seen IT Manager become far more upset by the time and money it takes to maintain an application, more so then the upfront time and money to create it. I think the LAMP vs. Java conversation change drastically when you talk about it under this context.
Ok Vic, you can flame me now....
|
|
|
Message #182482
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
J2EE is not just an web app
J2EE is just not for an web app only. I am the architect for a complex enterprise application, where web interface happens to be only a small part of the big picture. An SOA stack happens to be the main interface for the system.
I am using light weight framework like Spring, but not as a replacement for the core J2EE stack, but more as a complement.
Sure tools can help our life easier. But some problems are inherently complex. Friendly tools do not make the complexity go away.
I don't see myself giving up on J2EE in near future.
Pranab
|
|
|
Message #182483
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
look for the right reasons...
projects fail because of wrong skills, wrong tools and the wrong people!
When there are so many wrong people with wrong skills using wrong tools isn't there something fundamentally wrong? So much effort went into making it possible to write java between jsp code, whereafter the advice is given not to do so??? We have statefull beans , better not use m. There is CMP but don't fine grain , what is this crap leave it out then. I have hope though as long as our spec makers get out of their ivory tower and don't get to democratic.
|
|
|
Message #182496
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
look for the right reasons...
Every language/technology has its gotchas, it's not Java/J2EE exclusivity. In C you had to watch out for the use of gotos, proper code structure (high coupling/low cohesion, huge LOC functions) and many other problems. In C++ you had template hell, multiple inheritance, bad operator overloading, among others. All built in the language but not reccomended because of maintenance problems they could generate. I am sure other languages/technologies have their "dark side" powers too! So it all boils down to knowing how to use the correct tool with the proper skills on the right problem. There is no perfectly fool-proof tool out there, there will be always someone "smart" enough to mess things up, no matter how simple or complex things are. So just don't blame the gun for the murder.
Regards,
Henrique Steckelberg
|
|
|
Message #182506
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Former CTO for Sun's J2EE App Server says J2EE may lose
Peter Yared, former CTO for Sun's application server, says that "Java/J2EE may lose out to Open Source technologies in the future, as IT managers are architects get tired of the time and cost of building in Java," <pedant>
But, gee JEE is already an OSS technology! (e.g. JBoss, GlassFish, Geronimo, etc. etc. etc.)
</pedant>
Here's the deal.
The thing folks seem to criticize the most about JEE is deployment. The deployment step is JEEs portability mechansim.
None of the other frameworks even address this step, simply because they don't need to play in that game. They are not concerned if the code you write against their container/framework is portable to another version, because there simply isn't another version. Since they don't design to a specification (at least an external specification), there is little chance of a competing container implementing the same functionality.
And one could argue, why should there be another a compatible, yet competing version? With OSS this rarely happens.
In fact, ActiveGrids whole tenet is that portability is a non-issue because you're going to run Linux anyway, on x86 hardware. They've decided that x86 Linux Is It.
But, personally, I like the fact that we have competing containers in the JEE space. There must be a dozen of them, and the competition promotes and improves the art, from management, stability, performance as well as new features outside the of the spec that may one day get rolled in to the spec.
If JEE were simply Suns locked, internal Java ORB/Transaction server, JEE would be nothing but a blip today. But its not, rather its become an industry phenomenon, and the Whipping Boy Du Jour. The 800 lb guerilla that apparently needs to be knocked off its pedestal.
So, yea, things like RoR and "LAMP" solutions may well offer varying paradigms for development. Yea, they may be more productive up front, but you have to ask if whatever upfront productivity they promise outweighs the proven performace, stability, scalability of modern JEE servers, and outweighs the VAST Java knowledge in the industry to back up those servers and produce those apps.
It's not like JEE is static, it's not like its standing still. Going back to the popular "Java is Good Enough" argument, it's true, Java is flexible enough to adopt many paradigms of development, and many of those are the more powerful by leveraging the platform and infrastructure that JEE provides.
While JEE offers a large amount of things, you can make it as lightweight as you want. You want to write a bunch of JSPs in some Model 1 style of mixed code/view logic? Go ahead, any JEE server will happily deploy that. What if your app is a single servlet that calls JDBC directly? Should I run that on a JEE server? Sure, why not. What if your app supports 2 people, surely a JEE server is overkill for 2 people. Why? Cherry pick the pieces that you want out of the stack, just like any other system. You don't have to master the entire stack to get an application working. Idle services consume very little in terms of resources (if any).
Isn't that a "waste" of a JEE server? Running an application that uses so little of its capabilities? Nope. How many folks run a Unix box with simply Oracle on it, despite all of those other Services that Unix provides? Is that a waste of Unix? Certainly not.
Same with JEE, if and when you want those services, they are there available for your application, in a container you already know, in a system you've already deployed, against a specification you're already familiar with. No grand paradigm shift required to use more and more of the JEE stack for your application.
Sure, you can deploy an app solely on Tomcat, but why should I bother when for, perhaps, an extra MB of RAM (if that), I can get JBoss, Sun, or Geronimo? Why limit myself up front? Why not learn one of THOSE servers rather than simply Tomcat, even if to simply deploy a small WAR file?
JEE is productive, today. It is performant, today. It scales, today. It is portable, today. It is cheap, today. And it will be here tomorrow. All of your CMP 2 beans, for example, aren't going to "go away" in EJB 3, when JEE 5 comes out, your code will Still Work. The code you wrote 5 years ago will Still Work.
RoR is buzzy and cool, it's also very young. Where will it be next year? Two years? 5 years? Where will ActiveGrid be in 5 years? I dunno. I can't say where JEE will be in 5 years, but I certainly have more confidence in the longevity of JEE, in its specification, in its implementation, and in its knowledgebase.
If ActiveGrids paradigm is that earthshaking and wonderful, no doubt someone will move it on top of Java and the JEE stack in due time.
JEE is not perfect, none of these techs are, but Java and JEE combined is a flexible, powerful, performant platform.
|
|
|
Message #182522
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Gee Thanks Peter Yared
Given the fact that Mr.Yared was CTO for Sun's Application Server and obviously had some impact and say on all the issues that he's complaining about as far as specs go, why is everyone so forgiving with his new venture.
In fact, I think ActiveGrid might be hampered given the fact that he "failed" in the J2EE space. Now he's found some new snake oil that's "much better" to sell into the marketplace.
Sarcasm aside, J2EE is in trouble because of the J2EE community. Anyone who peruses or participates in supposed industry newsgroups and forums find nothing but trash talking and pontificating. Not a whole helluva lot of constructive input.
The bottom line if JEE is to survive, IT managers are going to have to feel comfortable with allocating financial and human resources to solve a problem. Right now there seems to be utter chaos regarding JEE's direction or focus. The main push with JEE is/was economy of scale where the "Network is the Computer". It's a tough sale in these lean budgetary times. Fast, cheap and it works is the mantra nowadays even though maintenance and TCO is debatably expensive. So I will concede the ROR and LAMP stuff is appealing for some projects.
|
|
|
Message #182531
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
J2EE will survive and prosper - just use the right tools
Ha, ha. What a load of hogwash. I whip out J2EE apps and Web Apps in particular a lot faster than with anything in the LAMP land (including Ruby on Rails). Use the right tools and the supposed complexity is absolutely no issue at all. I switched to JSF and Sun Java Studio Creator as soon as it became availble for web apps -- creating database driven web application has never been easier. Bottom line, use the right tools and you can easily forget all this nonsense with LAMP.
|
|
|
Message #182536
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
J2EE may lose - NOT REALLY
Frankly, I'm tired of all the whining about J(2)EE - "Its toooo hard!, wah!". Enterprise development shouldn't be done by novices anyway.
In my experience it's simply that the benefit/cost ratio is not high enough for what many see as JEE applications. That again depends on what a JEE application means to you: if one develops SevletContainer/TemplateEngine/POJOs applications, is it still JEE?
The answer could be yes and no, depends on whom you ask.
--
Igor Zavialov
Factoreal Financial Data and Technical Analysis solutions.
|
|
|
Message #182537
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Do it slowly, I am in a hurry.
Why are we discussing scripting Vs Coding again? One is a quick hack the other is implementing a design. It depends on the IT manager what he/she wants to do. One of my managers used to say "Do it slowly, I am in a hurry".
|
|
|
Message #182541
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Do it slowly, I am in a hurry.
Increasingly, you can get quick...
and clean. That's the difference today. JEE *is* in trouble. This is yet another example of leadership in the Java space seeing the light.
I don't think enterprise development, as in 2-phased commit and hardcore ORM is in trouble. It's going to be the web UI on a RDBMS...the app that 60% of all Java developers write over and over...that's going to be the first hit in the Java space.
We're in dire need of
- A higher abstraction.
- A better community process.
- A clean start.
- Fresh ideas.
- Metaprogramming.
That's why Java's visionaries are leaving.
-bt
|
|
|
Message #182542
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
something will defeat Java EE some day
These knids of statements are amusing because it's true that something, some day, will defeat Java EE by being more productive / less costly and eventually eclipse it in market share. And it's highly possible that this will be innovated by the open source community.
What's unlikely, however, is that this killer will only be an open source framework and not have a major commercial vendor throwing its weight behind it, or if it is related to a larger social trend that expands beyond the developer-tools industry, such as the rise of the Internet coincided wtih J2EE.
What's also very unlikely is that the killer will be LAMP, specifically the MySQL and "P" portions of that acronym. PHP just isn't that interesting, it's a useful tool to build web pages, but it doesn't offer tremendous advantages over what Java or .NET has. Python is more interesting, but needs a robust infrastructure behind it before it becomes a language for enterprise systems. (Plus I'm personally rooting for Ruby)
Furthermore, all of this assumes that development paradigms will be the main market determinant in the future. I'm skeptical. There's too much fragmentation to forsee a small number of leaders. And all of these pronouncements of doom and gloom assume that existing companies will stick to their current business models, when it's clear that they probably won't. If big vendors adapt to the proliferation of development paradigms, then the startups will fade pretty quickly -- their "only kid on the block" strategy is not a sustainable advantage.
And let's not forget that "market" implies "money exchanging hands", not "number of downloads / installs". There's a story if something is used widely, but it's not as big a story as something being used widely AND creating jobs, profits, etc. Sure, it's been demonstrated OSS can help suck growth out of a market, but most of those markets were very young at the time (web servers and application servers). It's unclear how long or far that will extend for things like databases (MySQL has a very long climb ahead).
|
|
|
Message #182549
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Do it slowly, I am in a hurry.
We're in dire need of
- A higher abstraction.
- A better community process.
- A clean start.
- Fresh ideas.
- Metaprogramming.
That's why Java's visionaries are leaving. -bt
From my perspective, the Java space addresses at all of your "ideals" with maybe the exception of the phrase "clean start" which really doesn't mean anything tangible anyway.
|
|
|
Message #182557
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
LAMP maybe, Java hopefully, JEE probably not
Agreed. I think its time we had a marketing term that stood not for what J2EE 1.4 is today (with all the old horror stories of EJB 2.x, Entity Beans and such like) - but for the new simple lightweight approach to developing in Java while reusing those JEE services you actually want.Strong contenders seem to be POJO or Spring? Its easy to show LAMP being more lightweight than a traditional JEE development - its much harder when comparing it to modern POJO approaches with Java IDEs and Spring. James Agreed. But we definitely need the P of LAMP in the Java Space . From my point of view there was and still is a large underadressed requirement space in J2EE, which is being adressed by Groovy and likes and which (--too? ) slowly is beeing picked up and adopted by the J2EE community (JSR 241 and Groovy as RI). There are simply things in the EE requirement space on which you do not want to spend so much time on, simply because the code life-cycle is bound to be short.
Best of both (all) worlds would bring J2EE a competative edge: engineered frameworks, pojo's, light-weight container's, and fancy scripting as glue.
Besides from the fact that Java can be made much more powerful by something like groovy, but that's altogether another story.
Forget about the EJB's... and from my not very representative opion about ORM altogether ....
We need a away to use SQL in very unobstrusive way, something which in the J2EE has'nt been adressed satisfactorly (at all) ... At least we can say that the community doesn't agree here at all...
Groovy is maybe again showing (hinting) the way? In Spring configured containers? Which populates a POJO Domain Layer? And Service Layer, which can be used however?
And then we IDE's which support the mix ;-)
Chris
|
|
|
Message #182560
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Perl instead of Java
well, then lets go ahead and code the next enterprise-level project in Perl, and see how well we fare.
This is so ridiculous that every other line of comment would be a comeplete waste.
|
|
|
Message #182583
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
J2EE may lose - NOT REALLY
My point is that JEE really isn't hard once you know what you are doing. Its not hard relative to many of the enterprise-level challenges JEE was designed to address. It is more cumbersome than it needs to be, but its improved alot in that area over the past 5 1/2 years.
I find that the the real difficult challenges are nailing requirements, architecture and design. Most people in IT aren't very good at it from what I've seen. Programming business applications if really not very hard at all if you've done the other things right. Of course it helps if you've designed for reuse and included appropriate frameworks and wrappers so your programmers aren't each solving the same problems. It also helps if you've organized your teams so that no one has to be an expert in everything JEE. People can easily master parts of it and work together with others who have mastered other parts. Enterprise applications aren't supposed to be implemented by one or two people. Compared to what I faced doing things in earlier technologies that are similar to what I do in JEE, we've come a long way.
So many of these complaints remind me of years ago when a VB programmer argued that VB was a good 3 tier development tool because you could run it on the client and the server. If only that was all there was to it. I pretended to agree and added that it was also infinitely scalable because you could run copies on as many PCs as you could afford. ;)
|
|
|
Message #182593
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Perl instead of Java
well, then lets go ahead and code the next enterprise-level project in Perl, and see how well we fare.
Spring home page and the Struts wiki page are writen in Python, that might give you an idea to think.
Anyway, when you are in a hole, and you have seen nothing else, you need to get out the hole and look down at it from above; then you realize that there is more.
Just consider and try write something you need in Groovy and see if you get more millage, YMMV. (We already have to write short bash or cygwin scripts... that is how you can start, and be more dynamic). The code is a lot more readable when you do heavy lifting. It's OK to have more than one lang. on your resume.
.V
http://roomity.com = RiA Community
|
|
|
Message #182678
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
J2EE will be just fine
IMHO, J2EE will be just fine. It'll take the best ideas from multiple open source products (i.e. Hibernate --> EJB 3.0) and will serve as a standard way of developing Enterprise Java applications.
People will always complain about some missing features in J2EE, but at least you won't stuck with some great but proprietary product in the middle of the project.
Other people will always praise some great features of a particular Java framework, but when it comes to automating an Enterprise, I'd stick to big guys (read J2EE) adding selected open source products, where it make sense.
Best,
Yakov Fain
http://www.weekendwithexperts.com
|
|
|
Message #182722
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Do it slowly, I am in a hurry.
I think J(2)EE is well and alive. Where are they leaving? Ruby on rails? .Net? LAMP? I think they are just retiring.
|
|
|
Message #182732
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
So why...?
So why is neither amazon nor google coded with J2EE if J2EE is a lot faster than anything in LAMP land?
|
|
|
Message #182757
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
So why...?
So why is neither amazon nor google coded with J2EE if J2EE is a lot faster than anything in LAMP land?
Who said they aren't?
Peace,
Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java
|
|
|
Message #182764
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Google uses Python
FYI, Google is neither coded with J2EE nor PHP. They use Python. Donno about amazon.
|
|
|
Message #182791
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Perl instead of Java
theres nothing wron with other languages, of course, although I still doubt whether Perl should be on the list of serious contenders for the enterprise space. I used to live off of Smalltalk programming, and still have that warm fuzzy feeling when I look back. I do recognize the merits of python (although..).
I think what matters for large-scale development is to have a language with a good and complete set of object-oriented features. Beyond that, its the infrastructure that matters.
So, if you are looking for an easy-to install CMS for a community site, and dont intend to customize it on the programming level, get one of them PHP CMS's, by all means. If you need to develop, you may be well off with Python. If you need enterprise-strength infrastructure and tools, theres no match for java IMO.
|
|
|
Message #182792
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
springframework on python?
Spring home page and the Struts wiki page are writen in Python
BTW, what makes you think springframework.org was written in python? I can see evidence that it runs on Drupal, which is a nice PHP CMS.
|
|
|
Message #182875
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Do it slowly, I am in a hurry.
That's why Java's visionaries are leaving. -bt
A very broad and generalised statement, surely? We are talking about JEE here. Java is, of course, very much more than just JEE. Perhaps 'some JEE people are disenchanted' would be a more appropriate statement?
|
|
|
Message #182902
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Google uses Python
FYI, Google is neither coded with J2EE nor PHP. They use Python. Donno about amazon.
I responded to this earlier, but the response disappeared.
First, Google certainly does use a ton of Java, and it is involved in every search.
Amazon also uses a ton of Java.
The concept of a simple directory of Python files making up Google or Amazon is laughable. Those are big businesses that have many applications making up what appears to be a simple website. Many of those applications are built in Java.
Peace,
Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java
|
|
|
Message #182909
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
We're in dire need of
J2EE is in dire need of a higher level of abstraction.
I'd also agree with "clean start" and metaprogramming.
I posted this link over on JavaLobby in March, 2005,
and it caused a fuss, but I think it's a valid argument-
http://www.realmeme.com/Main/savingj2ee/index.jsp
What J2EE really needs a development methodology
that focuses on removing complexity from the
design & dev process. We have methodologies that focus
on response time (XP), organizational politics (Waterfall),
risk management (RUP), but none that focus
explicitly on managing complexity in the process
itself.
|
|
|
Message #182933
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Google uses Python
Hi Cameron.
I may have jumped to conclusions when I read for instance:
http://webservices.sys-con.com/read/49156.htm that google and amazon run the LAMP stack. On rereading the excerpt it only states that they run "XML, open source, and grid computing" ...
Where did you find the information on google and amazon using Java?
Thanks /Dave
|
|
|
Message #182945
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Google uses Python
Where did you find the information on google and amazon using Java?
You can find some information in articles, but most of it is woefully out of date.
You can talk to the Java developers at JavaOne in the Google booth. (You may have also noticed that Google hired Josh Bloch, Cedric Beust, Bob Lee, Gregor Hohpe, ....)
Most of my knowledge on the subject comes directly from architects and Java developers that work at those companies.
And just to be clear, the fact that companies use Java doesn't imply that they don't use LAMP also.
Peace,
Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java
|
|
|
Message #182978
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Google uses Python
Hi Cameron.
I may have jumped to conclusions when I read for instance: http://webservices.sys-con.com/read/49156.htm that google and amazon run the LAMP stack. On rereading the excerpt it only states that they run "XML, open source, and grid computing" And anyone who uses Google as a prima facie "way to do things" for "the enterprise" needs to have their head examined, as the Google Application is pretty far removed from any actual enterprise I've ever worked with.
The Google model works well for Google because Googles parameters are availability and performance, with those little tasty nuts called "accuracy" and "consistency" being shoved in the back. Google does not need to be accurate, nor consistent. If it takes a week for a web page to show up in Googles search, so what. If two different servers in Googles cluster return different results to the same query as change bubbles through the system, no big deal.
As an end user you won't notice.
Apply those same metrics to a stock trading or distribution system, and you WILL be getting phone calls. Loud, angry phone calls from folks wearing pretty clothes and working in fancy offices.
Googles scope and scale means that inaccuracy and unreliablilty are not a detrimant to the entire system, and is therefor a readily scaleable application. When hardware is your primary scaling and growth metric, the individual application components performance then becomes secondary to the overall operation.
So, Google could be writing their front ends in Chipmunk BASIC for all we know, or care. Google will pick the platform(s) that balances development and performance, as a 10% slow down in performance on the front end means 10% more machines and network infrastructure to make up for it.
But Googles infrastructure, operations and design goals are quite contrary to what most conventional Enterprise systems require, and while they are a very successful large scale computer application, they are different enough that they should not be considered a benchmark to judge or model others by.
|
|
|
Message #182992
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Google uses Python
Google does not need to be accurate, nor consistent.
Sure .. for searches it can miss data etc.
For ads though, there's money attached. In fact, over 98% of their revenue is attached .. which sounds like an enterprise app to me ;-)
Peace,
Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java
|
|
|
Message #183058
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I disagree that J2EE is not there in future
"Peter Yared" may be right when he is talking about some very small applications/web apps, the scope of which will be really really small and specially you know it in advance about the boundries of your apps, but in reality it is not the same, once you start project most of the people make plans including functional domains and timespans and thought that its correct but in most of the cases thats false.
So if you are talking about Enterprise and are not sure what it will be lead to then choose "JAVA" and even not MS based apps, then you are on safe side as Java platform is there from a while now and have grown with the real time requirments, a Big example of this is "Think what ever you want to search about Java Platform" perform a simple search in Google and you will find something which is not the same with other apps.
|
|
|
Message #244653
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Many have an inaccurate picture of LAMP
J2EE gets used in hundreds and hundreds of circumstances where it's just way too complicated - and Java developers seem to have this mindset that overly complicated code that costs hundreds of thousands of dollars to deploy is a good idea.
Yes, there are definitely some cases where it's the best tool for the job. But 95% of the time, the same goal could be accomplished with LAMP for a lot less time and money. NAME FIVE WEB APPLICATIONS THAT COULDN'T BE DONE WITH LAMP. The exception is integration with legacy systems - that you really do need Java for.
People shun PHP because they see it as only for kids and as a hackish, amateur language that encourages bad code - and it's not suited to enterprise, blah blah blah. And yes, straight PHP does allow for bad code.
But Java developers choose to ignore the fact that there are frameworks (Symfony, Zend Framework, CakePHP) that allow for development just as structured and stable as Struts or Spring.
(I speak with functional experience in LAMP/php and having tinkered around with Struts, Struts 2, and Spring MVC. I have a decent understanding of basic Java OO structure - the same as PHP's OO system except on a couple of points.)
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman continues to explore the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(January 21, Article)
Ted Neward is an independent consultant specializing in high-scale enterprise systems, and an authority in Java and .NET technologies. He is the author and co-author of several books, including Effective Enterprise Java. At TheServerSide Java Symposium in March, he will be presenting sessions on pragmatic architecture, ECMAScript and Scala.
(January 15, Article)
Now that Oracle is absorbing Sun Microsystems, there mixed views on what should come of the Java Community Process (JCP). While some say Oracle should become the new steward of Java and keep the JCP much as it was, others argue that it may be time to open-source this widespread language.
(November 24, Article)
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
Download the entire book of Jakarta-Struts Live and learn about Struts MVC, Tiles, the Validator, DynaActionForms, plug-ins, internationalization, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
