Java: Dead Like COBOL, Not Like Elvis?

Home

News: Java: Dead Like COBOL, Not Like Elvis?

  1. Java: Dead Like COBOL, Not Like Elvis? (377 messages)

    In an interview with idevnews.com, author Bruce Tate says Java/J2EE is facing dramatic change, and could be "dead like COBOL, not like Elvis." But, Tate also says there is much hope, mostly coming from influences from open source projects and other languages - and he adds that the JCP is ineffective.
    IDN: How did you come to look outside the traditional Java community for technologies and ideas that could benefit the developer?

    Tate: The motivation for me came from an experience I had. My career to that point had been completely dedicated to Java, with years of working in [corporate IT], and I even have had three Java One best sellers on Java. I was working on a project to build a web front end onto a backend with a complex data model. In Java, it was just taking too long. I had been working on the project for four months, and I still wasn’t finished.

    I started saying to myself, 'This [project] should not be taking this long.' So, I asked some other developers I knew. Dave Thomas told me about Ruby on Rails, and it sounded OK but I just thought the project I was working on would crush it. But, I found out, Ruby on Rails worked out really well.
    Bruce then goes on to say that he modeled the database in two days with Ruby on Rails, with a partner finishing the application in four nights. This begs the question of what takes longest when working on projects? When you are working on a complex data model in Java, is the data model complexity where the time is spent?
    IDN: How did you come to that point of view, after being a Java developer for so long?

    Tate: First, I had to admit that not all answers are coming out of only the traditional Java community. I had just gotten in the frame of mind that Java is THE strong, rich source of new technologies. But, when a practical project need forced me to look outside Java, I found very interesting things happening.
    Has this truly been the case? What makes up the 'traditional Java community?' Is Spring a result of that community? After all, many (including Bruce Tate) look to Spring as being an example of how open source, community development can make leaps in terms of implementation simplicity and speed; are the ideas encompassed in Spring "non-traditional Java?"

    Threaded Messages (377)

  2. The many problems with this[ Go to top ]

    I have noticed that Java developers seem to have this impression that all other languages are dead and no one uses them. This is simply not true. "Dead like COBOL" I would waiger that there are more lines of active COBOL code in the world today than Java. Also, if COBOL is dead, then it had a good 4 decade run. I hope Java has the same.

    Useless we can actuall look at what he did in Java and what was done in Ruby, we shouldn't conclude that he is correct. Just because he wrote some books, doesn't make him an expert. 4 months Java = 2 days Ruby?
  3. COBOL IS NOT DEAD FOR SURE[ Go to top ]

    "COBOL is dead" >>> where I work, there are more COBOL programmers then any other langauge!! so I don't think that COBOL is dead or will be dead in the next 10 years.

    Java is strong, and it is getting stronger and stronger in the server side. however, yes, we really need to work a lot in the client side.

    Adel
  4. COBOL IS NOT DEAD FOR SURE[ Go to top ]

    "COBOL is dead" >>> where I work, there are more COBOL programmers then any other langauge!! so I don't think that COBOL is dead or will be dead in the next 10 years.Java is strong, and it is getting stronger and stronger in the server side. however, yes, we really need to work a lot in the client side.Adel

    Yes, but I bet you don't have many or any new projects starting in COBOL. Or course COBOL will exist as long as there is still software written in it, for maintenance and additional feature reasons. Some companies can't justify rewriting an inhouse application, if the current one is efficient and meets their needs.

    Ilya
  5. RoR vs Java Again???[ Go to top ]

    Ruby on Rails really has a chance to make a dent in many of the web UI/database problems that Java was designed to solve.

    Come on people, this is not a valid comparison, RoR does not compete with JEE, I like to see how they do an complex application with an DB with 100+ tables with ActiveRecord, you cannot base your application 100% on the DB design, it is a poor design, the DB and business rules need to be separated. RoR IMHO does not work for legacy DBs and RoRis JUST for smaller projects, TSS need to stop posting articles that make wrong comparisons...
  6. Open Source[ Go to top ]

    Ruby on Rails really has a chance to make a dent in many of the web UI/database problems that Java was designed to solve.
    Come on people, this is not a valid comparison, RoR does not compete with JEE,..

    I don't think this was the main thrust of Bruce's interview. I think the point he was making is how should we go about innovating.

    He makes the point that the open source model is a lot better at doing this. I agree.
  7. RoR vs Java Again???[ Go to top ]

    Ruby on Rails really has a chance to make a dent in many of the web UI/database problems that Java was designed to solve.
    Come on people, this is not a valid comparison, RoR does not compete with JEE, I like to see how they do an complex application with an DB with 100+ tables with ActiveRecord, you cannot base your application 100% on the DB design, it is a poor design, the DB and business rules need to be separated. RoR IMHO does not work for legacy DBs and RoRis JUST for smaller projects, TSS need to stop posting articles that make wrong comparisons...

    I just can say: +++ +++ +++ +++!!!

    You definitely mentioned the right think. See also

    http://hanzz.lbs-logics.at/index.php?option=com_content&task=view&id=64&Itemid=2

    for my comments.
  8. Dead like PL/1?[ Go to top ]

    Fact:
    1.Upcoming JSE 6 does not include GroupLayout (Netbeans Matise layout)
    2.Upcoming JEE 5 does not include Portlets.
    End of story.

    Not even fair to mention what other features other tech stack DO include now relative. Clients and Developers are being chased away from where I see.

    .V
  9. Dead like PL/1?[ Go to top ]

    Fact:1.Upcoming JSE 6 does not include GroupLayout (Netbeans Matise layout)2.Upcoming JEE 5 does not include Portlets.End of story. Not even fair to mention what other features other tech stack DO include now relative. Clients and Developers are being chased away from where I see..V

    What in the world are you talking about? This is why clients are being chased away? Because of GroupLayout and lack of JEE support for portlets? Ruby or other languages have that support? Even if the portlets are not going to be included in the JEE 5 support, I'm sure there will be great quality implementations out there you can use.

    Ilya
  10. Dead like PL/1?[ Go to top ]

    Ilaya,
    lack of JEE support for portlets? <snip> other languages have that support?

    I know that last year C# 2 shiped support for WebParts and Master paages, and that it works out of the box in the free SDK!

    How hard do developers and clients have to work to integrate vendors "left behinds" ? And then explain hours you had to do bit-twidling in the tech stack. Can they at least try to compete.

    JEE including or not including Portlets is important.

    .V
  11. Dead like PL/1?[ Go to top ]

    Ilaya,
    lack of JEE support for portlets? <snip> other languages have that support?
    I know that last year C# 2 shiped support for WebParts and Master paages, and that it works out of the box in the free SDK! How hard do developers and clients have to work to integrate vendors "left behinds" ? And then explain hours you had to do bit-twidling in the tech stack. Can they at least try to compete.JEE including or not including Portlets is important..V

    But C# has other drawbacks, single vendor, one platform, etc... I never compare JEE to C#, I don't see why other do. Unless we're ready to switch to a single platform enterprise, and all but windows, it takes a last seat in my book. It's great for analytical client applications though, or maybe putting a lightweight front end to OLTP.

    Ilya
  12. Analogy[ Go to top ]

    Wow almost 50 replies to a RoR thread and nobody has said "When you have a hammer in your hands, everything look like a nail" so far. I'm confused! And Rolf doesn't seem to post anymore. What's going on TSS?
  13. Dead like PL/1?[ Go to top ]

    Ilaya,
    lack of JEE support for portlets? <snip> other languages have that support?
    I know that last year C# 2 shiped support for WebParts and Master paages, and that it works out of the box in the free SDK! How hard do developers and clients have to work to integrate vendors "left behinds" ? And then explain hours you had to do bit-twidling in the tech stack. Can they at least try to compete.JEE including or not including Portlets is important..V

    I do not know, but any modern J2EE portal supports portlets. And some of them are also free. I do not see a problem.

    Also you can bundle your specific Swing layout manager with your app if you want. I do not see it as an overkill ...
  14. Ruby is great, but...[ Go to top ]

    Before I actualy looked into Ruby (I haven't really worked with RoR much, other than read a few article and tried a simple sample app), I didn't give it any credit. Well, that has changed, Ruby is truly a beautiful language, but...

    Ruby does not and I doubt ever will, have the commercial support and standards committee like Java. These are the most important factors for enterprise technologies. If you're an independent consultant and are writting an app for a small/midsize client (who doesn't have a clue), they'll let you write it in anything to save the bucks. In that scenerio, if you love Ruby (RoR), it might be a good choice.

    In most enterprise application cases, there is more to writting an app than the beauty of the language.

    The other day, I was trying to make a case to make a client of mine use RoR, so that I can learn it and they can save some development time associated costs (so I've been hearing:-). I was done in about 2 minutes, after I couldn't come up with a viable enterprise quality/grade deployment platform for RoR. Even in the RoR book, they describe multiple deployment scenerios, lighttpd with FastCGI, apache with mod_ruby or fastCGI where the only two recommended for production. The first is said to be unstable sometimes (these words are directly from the book), and the second is no longer actively supported/developed. So how comfortable would a company feel in deploying their app in an unstable and/or unsupported environment. So until Ruby has a viable platform, commercial and/or open source, which has a lot of traction, money behind it, etc..., it's a huge risk for any corporation to take on.

    For some reason, Ruby folks are not jumping on building a quality server platform, as say mod_perl/Apache, and even Python enjoys. I mean, what good is RoR without anywhere to deploy it?

    Ilya
  15. Ruby is great, but...[ Go to top ]

    [...]lighttpd with FastCGI, apache with mod_ruby or fastCGI where the only two recommended for production. The first is said to be unstable sometimes (these words are directly from the book), and the second is no longer actively supported/developed.

    Where does it say that FastCGI support is no longer actively supported/developed? It seemed to me that this was by far and large the best deployment option. Any links? Cheers.
  16. Yes, but..[ Go to top ]

    If I have to learn another language, wont I find myself getting confused when I switch back and forth between languages?

    Wont I need another set of tools and scripts for compiling/deploying?

    Wont I lose the ability to re-use my favorite libraries - i.e; DOM4J, Spring, Log4j, Hibernate, JUnit, etc..?

    For a language that is not yet mainstream, wont it be harder to "google" for answers to your technical questions, and find documentation and a community?

    Definately, we need to evolve and develop new languages as time goes by. But there has to be something BIG to get me to leave my comfort zone and community. From C++ to Java, it was the OS independence. I dont see it yet, with ROR.
  17. Yes, but..[ Go to top ]

    If I have to learn another language, wont I find myself getting confused when I switch back and forth between languages?Wont I need another set of tools and scripts for compiling/deploying?Wont I lose the ability to re-use my favorite libraries - i.e; DOM4J, Spring, Log4j, Hibernate, JUnit, etc..?For a language that is not yet mainstream, wont it be harder to "google" for answers to your technical questions, and find documentation and a community?Definately, we need to evolve and develop new languages as time goes by. But there has to be something BIG to get me to leave my comfort zone and community. From C++ to Java, it was the OS independence. I dont see it yet, with ROR.

    I miss a lot of things when I work in RoR. Simple example, I needed an app to generate secure PayPal buttons. In Java this is about 40 lines of code that uses the JCE APIs. In Ruby there is nothing similar so you are simply not able to do this. End of story. I ended up with writing a simple web service in Java to do the crypto work so that the Ruby app can still have this functionality. Works ok, but it is not ideal.

    Many other things. I really miss JMS in the Ruby world. I miss the well defined APIs of the standard Java runtime. I miss the quality documentation. The many more resources available in books and online. I miss simple things like an IoC container, a choice of web servers, Jakarta Commons. I miss things like JMX to monitor my app, etc.

    I've asked people on for example Ruby newsgroups and in chatrooms about the above things and I usually get the same reaction as from the Python people: "you don't think in a Ruby way". Personally I think these people simply don't know any better. Java is a very rich platform with many choices and available tools. Ruby and other scripting languages are much more limited.

    Sure, the language is really nice and has many features that make it so much less verbose and more powerful than something like Java. But a language is just one side of it. I need frameworks to get my job done. Most advocates don't understand that.

    Sorry for the rant. I'm actually a happy user of both, you just need to know when to use the right tool for the right job :-)

     S.
  18. Java is no longer compelling[ Go to top ]

    Java has run its course. SUN and IBM are now trying to figure out how to take all this open source and invent vendor lockin by making things so complex that only established vendors will have the money and the interest to do things nobody is really that interested in in the first place.

    Finally Java developers are realizing that hey, we are OVER ENGINEERING EVERYTHING. Partially because we are getting our asses kicked by overseas outsourcing to companies that get paid to write C in Java.

    We have been snowed by the heavyweight MVC police for so long that there is not even one RAD solution in Java.

    Because we are *above* RAD. But if Java is good for heavy it should be good for light. But then you would have to compete with .NET or Rails and it cant...so the whole standards copout and "whaaa I need a J2ee container coput get played".

    Whats the copout going to be when Spring kills J2ee containers?
  19. Java is no longer compelling[ Go to top ]

    Java has run its course.

    I love posts like these. They normally turn up on Slashdot, and go something like 'Intel is doomed', or 'Windows is on the way out', and, of course, 'Java is finished'.
    SUN and IBM are now trying to figure out how to take all this open source and invent vendor lockin by making things so complex that only established vendors will have the money and the interest to do things nobody is really that interested in in the first place.

    Strange, then, that many of the reference implementations of JSRs are open source, and not implemented by vendors at all! An example I am particularly interested in is JPOX, will will be the RI of JDO 2.0. Strange form of vendor lock-in. Another interesting example is Oracle donating JSF components to Apache MyFaces - a sort of 'anti' lock-in!
    Finally Java developers are realizing that hey, we are OVER ENGINEERING EVERYTHING. Partially because we are getting our asses kicked by overseas outsourcing to companies that get paid to write C in Java.We have been snowed by the heavyweight MVC police for so long that there is not even one RAD solution in Java.

    So what is RAD? Fast development - perhaps with a visual tool, with integrated debugging? Well, for client-side development there is NetBeans 5.0 with its awesome GUI tool. For server-side development there is Studio Creator, with its ability to produce data-linked web applications in a matter of minutes. That sure looks like at least two RAD solutions to me!
    Because we are *above* RAD.

    Well, I am not a fan of Studio Creator myself, but that is just me.
    But if Java is good for heavy it should be good for light.

    Like J2ME? Hmm....
    But then you would have to compete with .NET or Rails and it cant...

    Sure .... look at all those thousands of .NET apps on Linux, Solaris, HPUX... And those thousands of Rails jobs advertised out there.....
    so the whole standards copout and "whaaa I need a J2ee container coput get played".Whats the copout going to be when Spring kills J2ee containers?

    Er - perhaps things like JDO and JPA, which don't need J2EE containers? Standards with open source implementations?
  20. Java is no longer compelling[ Go to top ]

    Java has run its course. SUN and IBM are now trying to figure out how to take all this open source and invent vendor lockin by making things so complex that only established vendors will have the money and the interest to do things nobody is really that interested in in the first place.Finally Java developers are realizing that hey, we are OVER ENGINEERING EVERYTHING. Partially because we are getting our asses kicked by overseas outsourcing to companies that get paid to write C in Java.We have been snowed by the heavyweight MVC police for so long that there is not even one RAD solution in Java.Because we are *above* RAD. But if Java is good for heavy it should be good for light. But then you would have to compete with .NET or Rails and it cant...so the whole standards copout and "whaaa I need a J2ee container coput get played".Whats the copout going to be when Spring kills J2ee containers?

    Speak for yourself. Just because *YOU* are overengineering and *YOU* are getting your ass kicked doesn't mean that Java is compelling.

    Have you consider that YOUR stuff is overengineered and your ass is being kicked because you suck?
  21. Is Tate living in a cocoon. He says in the article "Well, look at it from a historical context. The problem Java grew up around solving was slapping a web UI around legacy stuff, mostly relational databases. The thinking was, and still is: ‘If you can solve that web-database problem very quickly, most of the time you will be important." Well, I've been doing Java and and JEE for a number of years in the enterprise space and "slapping a web UI" has rarely if ever been the focus for our use of Java. In Java's early days it wasn't even the web. People in corporations kept trying to write fat clients with Java. They thought they had a better more portable VB. Attempts to use it on the web beyond applets came later. The people who did think that Java was primarily for solving UI problems where the weenies and kids - the same types who think the world's important problems could/should be solved by spinning widgets in VB.

    As years have gone by and JEE has matured, we are increasingly using it to replace the backend systems and not just integrate with them. Tate says that in the article, but his tone implies that he thinks that sort of work is somehow less important. Well Bruce, its the sort of computing that runs the world. The UI's are just the icing. Amazon's one-click web interface wouldn't be very important if they couldn't obtain the product, ship it to you and collect the money. That's not done by a web UI.

    So for everyone like Bruce who thinks its all about the UI - please go chase after the next big UI toy and leave the real work to the adults.

    All that being said, I agree with a number of Tate's points and there is a lot to criticize about the JCP and the role of vendors in gunking up the platform and the ridiculous proliferation of "frameworks" and "standards". However, all this activity is actually proof that Java is not dead "like COBOL". The COBOL world has not experience that much diversity and change in decades, if ever.
  22. Yes the back end processing is important. IMPORTANT. However - one has to understand the importantce of the UI, if you think that UI is somehow secondary this is exactly the arrogance that gets an IT group in trouble with the clients. Tate is simply stating that existing J2EE set is not suitable for creating nice looking and functional UIs quckly as it should be in this day and age. I agree. Many, may times I would have to write some JavaScript in web application spending hours and sometimes days that I would not even think about if I was using Microsoft platform... I would dare to reverse your example - if Amazon did not have a nice UI there may not have been all this need to write a robust back end to process all these orders. How about 1-Click orders on Amazon? This is one of their most prised posessions , if I am not mistaken there was a legal proceedings at some point with someone else for the right do to a 1-Click orders.
  23. I don't buy this story for several reasons.

    You cannot tell me that an experienced team of two Java programmers spend 4 months working on an application, getting the job not done and then doing a rewrite in less than a week.

    Either the numbers don't add up, Bruce is not telling the whole story or the experience of those developers was not so brilliant after all.

    Sure, RoR is great, and I can also crank out a complex data model in minimal time. But really, with Hibernate 3.1 I can do it in the same time. In RoR I edit SQL code and create mostly empty model classes and with Hibernate I just write model classes with some annotations added.

    Maybe Bruce spend 4 months building this app in a classic J2EE/1.3 environment; Struts, Entity Beans, etc. Well, we all already knew that it is pretty difficult to be agile with that combination.

    So, invitation to Bruce: why not give us fill disclosure about what went really wrong in the original project?

     S.
  24. "...cannot tell me that an experienced team of two Java programmers spend 4 months working on an application..."


    "...does anything to sell ..."


    and thus most of the book writers. A good writer never will be a good developer.

    good.

    by lujan99@usa.net
  25. Java: Dead Like COBOL, Not Like Elvis?[ Go to top ]

    Boy, the TSS knows how to pick out a quote...don't they? Maybe I should provide a little context. So when someone reads Beyond Java, the question inevitably comes up like this:

    "So Java is dead, right?"

    And I need to respond without reciting a dissertation including all of the ideas in the book. And I think this quote captures the idea: old languages will someday be pushed to the back burner and new ideas will be expressed in something else, and the community will move on to something else. But old successful languages don't die. And the economy around them doesn't disappear.

    Since new languages come around every 10 years or so, Java is very much in danger of joining that camp. So when I say "Java is in danger", I mean it's in danger of losing the mindshare, community and innovation that go with being a dominant market leader. And I very much stand by that. I hope that Java can move more aggressively as a language, and I hope that we can take it forward as a platform that serves multiple languages.

    But I hardly think one sensationalized quote captures the spirit of the whole interview, the book, or my opinions, and I think that pushing out such a quote as a headline is a cheap trick to generate traffic. Certainly no conversation of substance will come out of it.
  26. Java: Dead Like COBOL, Not Like Elvis?[ Go to top ]

    Since new languages come around every 10 years or so, Java is very much in danger of joining that camp. So when I say "Java is in danger", I mean it's in danger of losing the mindshare, community and innovation that go with being a dominant market leader. And I very much stand by that. I hope that Java can move more aggressively as a language, and I hope that we can take it forward as a platform that serves multiple languages.

    What shape is ruby in? Its birthday will be in 13th birthday will be in 7 days

    http://www.ruby-lang.org/en/20030224.html
  27. Since new languages come around every 10 years or so, Java is very much in danger of joining that camp. So when I say "Java is in danger", I mean it's in danger of losing the mindshare, community and innovation that go with being a dominant market leader. And I very much stand by that. I hope that Java can move more aggressively as a language, and I hope that we can take it forward as a platform that serves multiple languages.

    What shape is ruby in? Its birthday 13th birthday will be in 7 days

    http://www.ruby-lang.org/en/20030224.html

    preview preview preview
  28. Java: Dead Like COBOL, Not Like Elvis?[ Go to top ]

    Boy, the TSS knows how to pick out a quote...don't they?
    ...
    and I think that pushing out such a quote as a headline is a cheap trick to generate traffic
    Well with respect TSS simply took the same headline of the quoted article ("Integrated Developer News" whoever that is)

    Next book going to be called "Bitter Java Programmer" ?
  29. Ruby will be dead before Java...[ Go to top ]

    Your assertion that 'Java is in danger' based on its age is just strange, to say the less.

    The facts :
    FORTRAN : 1954
    LISP : 1958
    COBOL : 1959
    C : 1971
    ADA : 1979
    C++ : 1983
    Perl : 1987
    Python : 1991
    Ruby : 1993 <--- !!!
    PHP : 1995
    JAVA : 1995 <---
    C# : 2000

    Ok. Ruby is two years older than Java. If Java is dying, are you just necrophil to play with Ruby?

    Let's face the facts... It took more than 10 years to build a framework (RoR) out of Ruby, while the first usable MVC framework for Java came out around 2000, 6 years before RoR. I found it pretty reactive for a dying body ...
  30. Your assertion that 'Java is in danger' based on its age is just strange, to say the less. The facts :FORTRAN : 1954LISP : 1958COBOL : 1959C : 1971ADA : 1979C++ : 1983Perl : 1987Python : 1991Ruby : 1993 <--- !!!PHP : 1995JAVA : 1995 <---C# : 2000Ok. Ruby is two years older than Java. If Java is dying, are you just necrophil to play with Ruby?...

    Good points.

    I had a look at some RoR tutorials at onlamp.com.
    And I must admit that RoR looks very impressing.
    So, my guess is that in the near future we'd see more and more PHP/Python/Perl web developers and hobbyists moving to RoR.

    But Java and .Net would remain for real enterprise developers.

    Arcadius.
  31. Ruby will be dead before Java...[ Go to top ]

    So, my guess is that in the near future we'd see more and more PHP/Python/Perl web developers and hobbyists moving to RoR.But Java and .Net would remain for real enterprise developers.Arcadius.


    Your first comments, I agree with. Majority of developers to move to Ruby will come from these environments.

    I don't understand what you mean by Java and .Net would be for "Real" enterprise developers. What's the definition of a real? Using a language (rather platform) that provides most of enterprise service implementations for you? Some might argue that it actualy creates an abstraction layer that makes the developers clueless as to the underlying implementation and though not as intelligent. I disagree with that, but also disagree with the fact that entperprise software has to be created in Java and/or .NET. I know of many enterprise grade software implementations written in Perl, Python, and Ruby is probably next. Why don't you ask Google about their heavy use of Python for underlying services? Or amazon for powering all of their web services in Perl? Or even British Telecom for implementing their Call Management Information system (in Perl). There are thousands more, that I'm not as familiar with.

    Enterprise developers, are just that, enterprise developers, classified by knowledge of the problem domain, technologies, implementation, possibly low level implementation, OO methodologies, patterns, etc..., but in no way is someone who knows J2EE and/or .NET be classified as an enterprise developer. That's like calling someone who drives a BMW a race car driver.

    Ilya
  32. Ruby will be dead before Java...[ Go to top ]

    So, my guess is that in the near future we'd see more and more PHP/Python/Perl web developers and hobbyists moving to RoR.But Java and .Net would remain for real enterprise developers.Arcadius.
    Your first comments, I agree with. Majority of developers to move to Ruby will come from these environments.I don't understand what you mean by Java and .Net would be for "Real" enterprise developers. What's the definition of a real?

    By "real enterprise developers", I meant those who work on big projects for large companies in the financial, healthcare, automotive, telecom, etc industry.
      Why don't you ask Google about their heavy use of Python for underlying services? ...

    About google...
    Google uses Java internally.
    If you followed the news, you'd have learnt that, some of the core Java engineers moved from SUN to Google (no need to cite names here). Moereover, there have been an article at sun.com about Google migration from Java 1.4 to 5.0.

    Arcadius.
  33. Ruby will be dead before Java...[ Go to top ]

    About google...Google uses Java internally.If you followed the news, you'd have learnt that, some of the core Java engineers moved from SUN to Google (no need to cite names here). Moereover, there have been an article at sun.com about Google migration from Java 1.4 to 5.0.Arcadius.

    Oh, I'm sure they do, actually Google is hiring Java, C/C++, Perl, Python, etc... developers. So I'm not discounting their heavy Java use. They leverage each technology for it's best features and not argue over what should be the true "one and only" standard within the enterprise. With various technologies, like CORBA and/or SOAP, you can leverage verious services within the enterprise, without sacrificing agility. I think languages will become less and less predominant, as they have been, and we'll see the usage of many languages and technologies within each company, interoperating with each other, in cross platform/language neutral way.

    Again, noone can argue the popularity and usage of other technologies I mentioned, Perl, Python, etc... in large enterprise-level applications. Each has it's own strength and weakness.

    Ilya Sterin
  34. Ruby will be dead before Java...[ Go to top ]

    I know of many enterprise grade software implementations written in Perl, Python, and Ruby is probably next.

    I'm not sure what "enterprise grade" is, but I do know that most software that purports to be "enterprise software" is not "enterprise software".
    Why don't you ask Google about their heavy use of Python for underlying services? Or amazon for powering all of their web services in Perl? Or even British Telecom for implementing their Call Management Information system (in Perl).

    FWIW, all three of those companies do most of their heavy lifting (in apps built in the past five years anyhow) using Java.

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  35. Ruby will be dead before Java...[ Go to top ]

    I know of many enterprise grade software implementations written in Perl, Python, and Ruby is probably next.
    I'm not sure what "enterprise grade" is, but I do know that most software that purports to be "enterprise software" is not "enterprise software".

    Well, the definition to enterprise software is very subjective any ways, I was more relating to software that is robust, scalable, extensible, interoperable, etc... Basically most properties that one would consider as "Enterprise Software". There are many of those written in variety of technologies. Yes, Java might enable some of these with it's frameworks/libraries vs. having to write one yourself, but it still doesn't mean that the same (or even better) can't be accomplished in any other general purpose language.

    I use Java 90% of the time, I wouldn't use anything else write now at client sites for most of the OLTP systems, but I'm always looking at and learning alternatives. And I will definitely employ RoR if I find a low risk project with a good fit.
    Why don't you ask Google about their heavy use of Python for underlying services? Or amazon for powering all of their web services in Perl? Or even British Telecom for implementing their Call Management Information system (in Perl).
    FWIW, all three of those companies do most of their heavy lifting (in apps built in the past five years anyhow) using Java.Peace,Cameron PurdyTangosol Coherence: Clustered Shared Memory for Java

    Well, I don't know about most, I know (as I mentioned in their post), that they use variety of technologies. And I wouldn't be surprised if they used Java heavily, it would be a great choice on their behalf, but... I know Amazon backend web services are all done in Perl, as well as BT is using Perl for very heavy data intensive tasks, etc..., as well as their Call Management Information system. Again, all I'm trying to say is that there is more than Java out there. I love Java, I'm not here trolling about other technologies:-), but it's just too many folks on here that act is if Java is irreplaceable and the global IT backbone would collapse without it. My post was merely for folks that say, I wouldn't write Enterprise Software in anything else.

    Ilya
  36. Ruby will be dead before Java...[ Go to top ]

    Wow, I need to slow down typing, amazing how you can type quick and make so many spelling and grammar mistakes:-)

    Ilya
  37. Ruby will be dead before Java...[ Go to top ]

    I'm not here trolling about other technologies:-), but it's just too many folks on here that act is if Java is irreplaceable and the global IT backbone would collapse without it. My post was merely for folks that say, I wouldn't write Enterprise Software in anything else.Ilya

    Well, what would you use for the core of any software system - the part that does the 'heavy lifting'? The part that needs to be efficiently multi-threaded and truly high performance? Perl, Python, Ruby?

    Traditionally this has been the area where C, and then C++ have dominated. Now Java is taking over, simply because it is easier to develop with. The reason that Java can take over is because it is a general-purpose language with proven concepts.

    My test for a language being general purpose is if you can write a high-performance compiler or database with it. You can with Java.
  38. Ruby will be dead before Java...[ Go to top ]

    I'm not here trolling about other technologies:-), but it's just too many folks on here that act is if Java is irreplaceable and the global IT backbone would collapse without it. My post was merely for folks that say, I wouldn't write Enterprise Software in anything else.Ilya
    Well, what would you use for the core of any software system - the part that does the 'heavy lifting'? The part that needs to be efficiently multi-threaded and truly high performance? Perl, Python, Ruby? Traditionally this has been the area where C, and then C++ have dominated. Now Java is taking over, simply because it is easier to develop with. The reason that Java can take over is because it is a general-purpose language with proven concepts. My test for a language being general purpose is if you can write a high-performance compiler or database with it. You can with Java.

    I think this post is a pretty good indication of where we've come. So is it a good idea to write databases, middleware and applications in the same language? That's the heart of the issue to me. I've decided that it's not, after coding applications in Java for 10 years. Most of Beyond Java, and the subsequent interviews were about Java as an applications language. Most Java developers are definitely applications developers. The SOA-type architectures will enable the heavy lifting and the light applications on top to be written in different languages.
  39. Ruby will be dead before Java...[ Go to top ]

    I think this post is a pretty good indication of where we've come. So is it a good idea to write databases, middleware and applications in the same language? That's the heart of the issue to me. I've decided that it's not, after coding applications in Java for 10 years. Most of Beyond Java, and the subsequent interviews were about Java as an applications language. Most Java developers are definitely applications developers. The SOA-type architectures will enable the heavy lifting and the light applications on top to be written in different languages.

    I think this post is a pretty good indication why Bruce Tate's arguments have come to a dead end: RoR is not designed as lightweight tier sitting on top of some SOA-type architecture. RoR is simply "slapping a web UI around relational databases".
  40. Simple is better or complex ?[ Go to top ]

    ... "slapping a web UI around relational databases".

    Which is more sophisticated? Simple, or Complex.
    What say the unwashed masses?

    Scales? Maintain? Time to market? Looks better (ex: negative space)?


    .V
    ps: It be simpler if vendors included Portlets in JEE, otherwise, I have to budget for i... iPlanet (glassfish) or Tomcat and I have to integrate and explain why we are not using MasterPages and WebParts... that are integrated. Otherwise call it an EJB server. There has to be something for non EJB apps.
  41. Simple is better or complex ?[ Go to top ]

    ... "slapping a web UI around relational databases".
    Which is more sophisticated? Simple, or Complex. What say the unwashed masses? Scales? Maintain? Time to market? Looks better (ex: negative space)?

    I'm not talking about RoR's suitability for rapid web development, I don't care about that. I'm talking about Mr. Tate's arguments. In particular, I do not see how RoR would fit into any SOA-type of architecture.
  42. Even though RoR is designed to be running on top of a database, I do see a perspective of running on top of components communicated to using something like XML-RPC, Corba, Soap or whatever (SOA). In a way the database is nothing else than this, but we don't see it like that, because databases are such an integral part of most applications.
  43. Even though RoR is designed to be running on top of a database, I do see a perspective of running on top of components communicated to using something like XML-RPC, Corba, Soap or whatever (SOA). In a way the database is nothing else than this, but we don't see it like that, because databases are such an integral part of most applications.
    I agree. In reality very few "enterprise" components have been produced. When EJB's and J2EE was first launched we were promised distributed enterprise wide components, there was even talk of a market in EJB components. But mostly due to the difficulties in distribution most applications are merely presentation on top of a database. I agree using "SOA" as component glue will merely result in presentation on top of SOAP. Which something like Rails could tackle readily.

    IMO Sun lost all ambition when they decided to follow Microsoft down the "SOA" path, whatever happened to JINI?

    Conservatism, and trying to out market Microsoft, has lead to what can only be described as technological stagnation.

    What surprises me is how everyone is getting so upset because someone dared to mention what many of use have been quitely thinking for a long time.

    Paul.
  44. Simple is better or complex ?[ Go to top ]

    ... "slapping a web UI around relational databases".
    Which is more sophisticated? Simple, or Complex.What say the unwashed masses?Scales? Maintain? Time to market? Looks better (ex: negative space)?.Vps: It be simpler if vendors included Portlets in JEE, otherwise, I have to budget for i... iPlanet (glassfish) or Tomcat and I have to integrate and explain why we are not using MasterPages and WebParts... that are integrated. Otherwise call it an EJB server. There has to be something for non EJB apps.

    What? I'm not trying to be rude, but what are you talking about?

    Ilya
  45. Simple is better or complex ?[ Go to top ]

    What? I'm not trying to be rude, but what are you talking about?Ilya
    You're not alone.
  46. Ruby will be dead before Java...[ Go to top ]

    I'm not here trolling about other technologies:-), but it's just too many folks on here that act is if Java is irreplaceable and the global IT backbone would collapse without it. My post was merely for folks that say, I wouldn't write Enterprise Software in anything else.Ilya
    Well, what would you use for the core of any software system - the part that does the 'heavy lifting'? The part that needs to be efficiently multi-threaded and truly high performance? Perl, Python, Ruby? Traditionally this has been the area where C, and then C++ have dominated. Now Java is taking over, simply because it is easier to develop with. The reason that Java can take over is because it is a general-purpose language with proven concepts. My test for a language being general purpose is if you can write a high-performance compiler or database with it. You can with Java.
    I think this post is a pretty good indication of where we've come. So is it a good idea to write databases, middleware and applications in the same language? That's the heart of the issue to me. I've decided that it's not, after coding applications in Java for 10 years. Most of Beyond Java, and the subsequent interviews were about Java as an applications language. Most Java developers are definitely applications developers. The SOA-type architectures will enable the heavy lifting and the light applications on top to be written in different languages.

    Firstly, you are missing the point of what I posted. We were talking about 'the global IT backbone'. By that term I was assuming we meant more than the niche that is web applications or client-side software.

    Secondly, simplu disagree. I have, over decades, seen so many projects fail because the latest RAD approaches collapse when there is some 'heavy lifting' required, which in my experience inevitably happens when a project grows above a certain size - when what starts as some lightweight interface over a database or other services grows into something more substantial. I also find it is hard to predict which projects will grow in this fashion.

    So, my view is that it is right to use a language that has the performance so that it can be used at all scales of development. I have seen too many projects crash and burn because they didn't.
  47. Ruby will be dead before Java...[ Go to top ]

    So, my view is that it is right to use a language that has the performance so that it can be used at all scales of development. I have seen too many projects crash and burn because they didn't.

    I agree with Bruce on this one. Why use the same language that you use to write device drivers to build enterprise applications? It just doesn't make sense. In the long run different languages will be used for different things, trading performance and accessibility. Martin Fowler has discussed this in his writings on DSL's and language work benches. Croquet, which I’ve mentioned before is also taking this approach.

    In a sense it is an extension of what we are already doing. I would guess that most Java VMs are written in C. So why not use a dynamic domain specific business language to script together Java components? In Croquet they are experimenting with end user scripting using a language called TVML, scripting together Smalltalk objects (components). The Smalltalk objects make use of an underlying C/C++ OpenGL library for rendering. As I said before one cap doesn't necessarily need to fit all.

    Paul.
  48. Ruby will be dead before Java...[ Go to top ]

    I agree with Bruce on this one. Why use the same language that you use to write device drivers to build enterprise applications? It just doesn't make sense. In the long run different languages will be used for different things, trading performance and accessibility.

    I know this may sound like an extreme position, but I think it can make sense (well, perhaps not device drivers, but certainly high-performance things like databases). If a language is efficient enough to write such things, you have a guarantee that it will cope with whatever you throw at it. You know that it will run well multi-threaded. You know that it can efficiently handle memory.
    So why not use a dynamic domain specific business language to script together Java components?

    Because I have so often seen the horrors than can result from this; bad decisions can be made about where the dividing line should be between languages.
  49. Ruby will be dead before Java...[ Go to top ]

    So why not use a dynamic domain specific business language to script together Java components?
    Because I have so often seen the horrors than can result from this; bad decisions can be made about where the dividing line should be between languages.

    This is what I meant when I said nothing is certain. I agree that this use to be the case, but times are changing. For example the language workbench implementations Martin Fowler talks about that allow you to seamlessly move the dividing line.

    In some situations the dividing line is clearer. Spring makes use of this and provides the ability to "script" together components using XML. So people using a three tier architecture can link together the tiers of their application in XML. Now looking forward we will want to link together enterprise wide components (actually we were promised this with EJB1.0...) rather than just components within a single app. What type of language will we need then? For sure it will need to be dynamic.

    Paul.
  50. Ruby will be dead before Java...[ Go to top ]

    So why not use a dynamic domain specific business language to script together Java components?
    Because I have so often seen the horrors than can result from this; bad decisions can be made about where the dividing line should be between languages.
    This is what I meant when I said nothing is certain. I agree that this use to be the case, but times are changing. For example the language workbench implementations Martin Fowler talks about that allow you to seamlessly move the dividing line.In some situations the dividing line is clearer. Spring makes use of this and provides the ability to "script" together components using XML. So people using a three tier architecture can link together the tiers of their application in XML. Now looking forward we will want to link together enterprise wide components (actually we were promised this with EJB1.0...) rather than just components within a single app. What type of language will we need then? For sure it will need to be dynamic.Paul.

    I don't believe that your analogy holds, because Spring doesn't script together anything using XML or otherwise.
  51. Ruby will be dead before Java...[ Go to top ]

    I don't believe that your analogy holds, because Spring doesn't script together anything using XML or otherwise.
    So why do they call it a bean factory? And why all that AOP style interceptor semantics? XML doesn't look like a scripting language granted, but that is exactly what it is being used for.

    Incidently EJB descriptors are used for a similar purpose. In dynamic languages none of this "IoC" is needed. Loose coupling and runtime binding come for free.

    Paul.
  52. Ruby will be dead before Java...[ Go to top ]

    I don't believe that your analogy holds, because Spring doesn't script together anything using XML or otherwise.
    So why do they call it a bean factory? And why all that AOP style interceptor semantics? XML doesn't look like a scripting language granted, but that is exactly what it is being used for.Incidently EJB descriptors are used for a similar purpose. In dynamic languages none of this "IoC" is needed. Loose coupling and runtime binding come for free.Paul.

    They don't call it scripting. AOP definitely has nothing to do with scripting.

    No offense, but it doesn't seem like you understand IOC, AOP, or Spring, which is why your analogy fails.
  53. Ruby will be dead before Java...[ Go to top ]

    <blockquoteThey don't call it scripting. AOP definitely has nothing to do with scripting. No offense, but it doesn't seem like you understand IOC, AOP, or Spring, which is why your analogy fails.No they don't call it scripting... No offence but it doesn't seem that you are capable of opening your mind and thinking for yourself :^)

    Paul.
  54. Ruby will be dead before Java...[ Go to top ]

    No offense, but it doesn't seem like you understand IOC, AOP, or Spring, which is why your analogy fails.No they don't call it scripting... No offence but it doesn't seem that you are capable of opening your mind and thinking for yourself :^)

    The wife and I were watching Ellen DeGeneres standup on TV earlier this morning and she was talking about "just kidding".

    "I hope you didn't pay for that haircut....just kidding"

    "I don't think you know the meaning of just kidding or we'd both be laughing"

    "No offense, but..."
  55. I'm out[ Go to top ]

    Hi All,

    I've partcipated in all three "beyond Java" discussions on TSS. And they've all gone the same way. Now in response to the last "blind ignorant" comment - I could of dug up papers on IoC such as the PicoContainer work at ThoughtWorks and evidence of the link between scripting languages and IoC, but why bother? Why educate the wilfully ignorant?

    I think the main issues here are not technical, but have to do with people and their comfort zones.

    So in conclusion here is what I've learnt:

    1. If you want to use a dynamic language for Agile development anytime soon, forget the JVM or the CLR - use a native dynamic language along with a native VM.

    2. Sun gave up on the idea of technical excellence long ago, and are busy trying to beat Microsoft at it's own game.

    3. The Java community are admiring their own navels and aren't interested in ideas from outside the Java world.

    4. Because of 3. the "next big thing" will not come from Java

    5. The "next big thing" will not come from the business sector either, due to their conservatism and the entrenchment of Java/J2EE and .NET (which are pretty much the same thing).

    6. Look to other sectors like Academia for true innovation - just like the creation of the Internet and the World Wide Web in the past. In this regard Croquet looks promising. Eventually the business sector will catch up... they always do.

    Peace and Out

    Paul.
  56. I'm out[ Go to top ]

    Here are some examples of what's been done by us in Spring
    I've got, for example, a junior developer who was able to take modify one piece of code that handles searching using Hibernates Query by example, query by criteria, and Spring's convienience classes ALL without really understanding how it works simply by examining the existing code.

    In a similar vein, I've added caching support to one of our objects using AOP and the open source OSCache. I wrote an interface that uses OSCache for this particular implentation and the caching is configured via Spring.

    By using the put or get method on the interface contained in that inteceptor one can add caching to one of our Business Object interfaces all without understanding AOP, Spring, or even OSCache.

    Also, a added a simple interceptor for profiling, in about 2 hrs, that prints for every Business object interface call the name of the object in question, method, execution time, arguments, and memory used before and after the call. By adding this interceptor to the business object definition in our business.xml file, one can add this to any call, again, without fully understanding AOP, Spring, or even the profile interceptor itself.

    The issue is that once a month an ROR article appears and eventually, someone says that you get all the ROR stuff with the excellent Java software available. Usually, the doubters have never used the stuff, like Spring, that is mentioned.

    Inevitably, it comes down to value add and whether or not Ruby adds it. I don't think it does. We've been hearing about scripting and dynamic languages replacing static ones for years and it has yet to happen.

    So when healthy skepticism is offered, and worse, counter-examples, accusations of closed-mindeness abound.

    Foolishness.

    I submit that not only does ROR not offer any real innovation, but it doesn't offer any real advantage beyond the current generation of software, like Spring, Hibernate, JDO, etc offers. I further submit that as long as one can come close to matching ROR perceived dev speed, and still scale up to more complex task(something that even ROR proponents say ROR cannot do) ROR will fail to evolve beyond any niche tool that has advocates, but fails to garner any mainstream use.
  57. I'm out[ Go to top ]

    Here are some examples of what's been done by us in SpringI've got, for example, a junior developer who was able to take modify one piece of code that handles searching using Hibernates Query by example, query by criteria, and Spring's convienience classes ALL without really understanding how it works simply by examining the existing code.In a similar vein, I've added caching support to one of our objects using AOP and the open source OSCache. I wrote an interface that uses OSCache for this particular implentation and the caching is configured via Spring.By using the put or get method on the interface contained in that inteceptor one can add caching to one of our Business Object interfaces all without understanding AOP, Spring, or even OSCache.Also, a added a simple interceptor for profiling, in about 2 hrs, that prints for every Business object interface call the name of the object in question, method, execution time, arguments, and memory used before and after the call. By adding this interceptor to the business object definition in our business.xml file, one can add this to any call, again, without fully understanding AOP, Spring, or even the profile interceptor itself.The issue is that once a month an ROR article appears and eventually, someone says that you get all the ROR stuff with the excellent Java software available. Usually, the doubters have never used the stuff, like Spring, that is mentioned.Inevitably, it comes down to value add and whether or not Ruby adds it. I don't think it does. We've been hearing about scripting and dynamic languages replacing static ones for years and it has yet to happen.So when healthy skepticism is offered, and worse, counter-examples, accusations of closed-mindeness abound.Foolishness.I submit that not only does ROR not offer any real innovation, but it doesn't offer any real advantage beyond the current generation of software, like Spring, Hibernate, JDO, etc offers. I further submit that as long as one can come close to matching ROR perceived dev speed, and still scale up to more complex task(something that even ROR proponents say ROR cannot do) ROR will fail to evolve beyond any niche tool that has advocates, but fails to garner any mainstream use.
    I said I wasn't going to do this but a Single google search and what do I find:
    NanoContainer builds on top of PicoContainer the support for several scripting meta-languages (XML, Groovy,
    Bsh, Jython and Rhyno), AOP, Web frameworks (Struts and WebWork), Persistence (Hibernate) SOAP, JMX, and much more.

    Straight on the PcoContainer website's front page:

    http://www.picocontainer.org/

    This is what I mean by closed minds. A massive rant on "what I am doing with Spring. And he hasn't even taken the time to look at the next most popuplar IoC framework in Java - never mind looking at other languages - never mnd realise that IoC containers are just not needed in dynamic languages etc...

    This is my point. Blind allegiance to what some one else as correctly described as a proprietary technology (Java).

    Last person I heard ranting like this was a Microsoft VB geek. The truth is that Sun and Microsoft are looking pretty similar these days.

    Bruce they'll never here you. Just get on with saving your clients time and money (that what they pay you for). These lot have got their egos tied up in a programming language for heavens sake.

    Now do you think the geek will have the decency to apologise..? Or even admit that he was wrong..? I doubt it.

    Paul.
  58. I'm out[ Go to top ]

    Thanks, Paul. Drop me an email some time. In any industry, there are early adopters, pragmatics and skeptics/conservatives. It's a long wave. People riding different parts of the wave can see vastly different things. If you're riding the crest of the wave as I am, and you're concerned about a specialized niche as I am, you can really see a loss of momentum. If you're a pragmatic, you're just starting to notice Rails, and only the front end of the pragmatics are even recognizing Rails or alternatives. But if you are a skeptic/conservative, or if you are an early adopter/pragmatic in another space like mobile, Java is really just getting reved up for you. It really is a massive wave.

    So in many ways, the replies are understandable. There are just so many unknowns out there. The biggest question in my mind has been can any other wave accumulate enough mass to survive all of the noise? I think I have the answer for one niche, for one customer set...but it's a very important niche.
  59. I'm out[ Go to top ]

    Thanks, Paul. Drop me an email some time. In any industry, there are early adopters, pragmatics and skeptics/conservatives. It's a long wave. People riding different parts of the wave can see vastly different things. If you're riding the crest of the wave as I am, and you're concerned about a specialized niche as I am, you can really see a loss of momentum. If you're a pragmatic, you're just starting to notice Rails, and only the front end of the pragmatics are even recognizing Rails or alternatives. But if you are a skeptic/conservative, or if you are an early adopter/pragmatic in another space like mobile, Java is really just getting reved up for you. It really is a massive wave. So in many ways, the replies are understandable. There are just so many unknowns out there. The biggest question in my mind has been can any other wave accumulate enough mass to survive all of the noise? I think I have the answer for one niche, for one customer set...but it's a very important niche.

    Bruce,

    This is the crap that pisses people off... "If you were as out ahead of the curve as I am you'd understand, but since you're stuck back in the pack..." Please. Can't you accept that some of us, while understanding that Java isn't the be-all end-all and won't be the best tool forever, also think that RoR is a BAD IDEA, not merely for large enterprise applications, but also for smaller data-driven web apps? Some of us feel that hacking together your web app in less time is meaningless compared to the maintenance costs and extensibility to handle more and more features, including integration with other systems and scaling to much larger user-bases.

    Just because you got stuck doing crappy little CRUD webapps and got bored, don't shake your new shiny toy in our faces and say "See! See! It's much cooler than the tools you've been using!". I'm sure what you were doing WAS boring, but building distributed processing, JMS / Database 2PC systems, and systems integration is sufficiently challenging for a lot of us that we don't really need to try to do it on a platform that can't be deployed reliably.
  60. Don´t blame - learn !!![ Go to top ]

    Thanks, Paul. Drop me an email some time. In any industry, there are early adopters, pragmatics and skeptics/conservatives. It's a long wave. People riding different parts of the wave can see vastly different things. If you're riding the crest of the wave as I am, and you're concerned about a specialized niche as I am, you can really see a loss of momentum. If you're a pragmatic, you're just starting to notice Rails, and only the front end of the pragmatics are even recognizing Rails or alternatives. But if you are a skeptic/conservative, or if you are an early adopter/pragmatic in another space like mobile, Java is really just getting reved up for you. It really is a massive wave. So in many ways, the replies are understandable. There are just so many unknowns out there. The biggest question in my mind has been can any other wave accumulate enough mass to survive all of the noise? I think I have the answer for one niche, for one customer set...but it's a very important niche.
    Bruce, This is the crap that pisses people off... "If you were as out ahead of the curve as I am you'd understand, but since you're stuck back in the pack..." Please. Can't you accept that some of us, while understanding that Java isn't the be-all end-all and won't be the best tool forever, also think that RoR is a BAD IDEA, not merely for large enterprise applications, but also for smaller data-driven web apps? Some of us feel that hacking together your web app in less time is meaningless compared to the maintenance costs and extensibility to handle more and more features, including integration with other systems and scaling to much larger user-bases. Just because you got stuck doing crappy little CRUD webapps and got bored, don't shake your new shiny toy in our faces and say "See! See! It's much cooler than the tools you've been using!". I'm sure what you were doing WAS boring, but building distributed processing, JMS / Database 2PC systems, and systems integration is sufficiently challenging for a lot of us that we don't really need to try to do it on a platform that can't be deployed reliably.


    I understand full loyality to Java from the following people:
    1) You work for SUN
    2) You get paid from SUN to defend Java´s pride
    3) Your business is tightly coupled on a continoued Java success - for instance you are a vendor and provide Service´s on Java based products.
    4) Your heart pacemaker is controlled by a JVM and thus your health is based on Java.

    If you dont find yourself in one of this categories the time has come to reboot your brain and reinit your "Language get_The_Best_Solution(Problem problem)" Method (notice: I´m using java syntax, Parameter is from type Problem, return value is Language)

    cheers,
    Andreas

    Like said, it is save to say that Java will not (and maybe never) disapear. Also it will remain an leading choice for Enterprise Computing, like to descripted.
  61. Don´t blame - learn !!![ Go to top ]

    Bruce, This is the crap that pisses people off... "If you were as out ahead of the curve as I am you'd understand, but since you're stuck back in the pack..." Please. Can't you accept that some of us, while understanding that Java isn't the be-all end-all and won't be the best tool forever, also think that RoR is a BAD IDEA, not merely for large enterprise applications, but also for smaller data-driven web apps? Some of us feel that hacking together your web app in less time is meaningless compared to the maintenance costs and extensibility to handle more and more features, including integration with other systems and scaling to much larger user-bases. Just because you got stuck doing crappy little CRUD webapps and got bored, don't shake your new shiny toy in our faces and say "See! See! It's much cooler than the tools you've been using!". I'm sure what you were doing WAS boring, but building distributed processing, JMS / Database 2PC systems, and systems integration is sufficiently challenging for a lot of us that we don't really need to try to do it on a platform that can't be deployed reliably.
    I understand full loyality to Java from the following people:1) You work for SUN2) You get paid from SUN to defend Java´s pride3) Your business is tightly coupled on a continoued Java success - for instance you are a vendor and provide Service´s on Java based products.4) Your heart pacemaker is controlled by a JVM and thus your health is based on Java.If you dont find yourself in one of this categories the time has come to reboot your brain and reinit your "Language get_The_Best_Solution(Problem problem)" Method (notice: I´m using java syntax, Parameter is from type Problem, return value is Language)cheers,AndreasLike said, it is save to say that Java will not (and maybe never) disapear. Also it will remain an leading choice for Enterprise Computing, like to descripted.

    Did you read what I said? I'm being pragmatic about what solves REAL PROBLEMS RIGHT NOW, not gawking at the shiny new toys. I KNOW Java solves these problems right now. Everything I've read says Ruby DOES NOT SOLVE these problems right now (especially since there doesn't even seem to be a stable deployment environment for it). In what way am I being a Java fan-boy?
  62. Don´t blame - learn !!![ Go to top ]

    Bruce, This is the crap that pisses people off... "If you were as out ahead of the curve as I am you'd understand, but since you're stuck back in the pack..." Please. Can't you accept that some of us, while understanding that Java isn't the be-all end-all and won't be the best tool forever, also think that RoR is a BAD IDEA, not merely for large enterprise applications, but also for smaller data-driven web apps? Some of us feel that hacking together your web app in less time is meaningless compared to the maintenance costs and extensibility to handle more and more features, including integration with other systems and scaling to much larger user-bases. Just because you got stuck doing crappy little CRUD webapps and got bored, don't shake your new shiny toy in our faces and say "See! See! It's much cooler than the tools you've been using!". I'm sure what you were doing WAS boring, but building distributed processing, JMS / Database 2PC systems, and systems integration is sufficiently challenging for a lot of us that we don't really need to try to do it on a platform that can't be deployed reliably.
    I understand full loyality to Java from the following people:1) You work for SUN2) You get paid from SUN to defend Java´s pride3) Your business is tightly coupled on a continoued Java success - for instance you are a vendor and provide Service´s on Java based products.4) Your heart pacemaker is controlled by a JVM and thus your health is based on Java.If you dont find yourself in one of this categories the time has come to reboot your brain and reinit your "Language get_The_Best_Solution(Problem problem)" Method (notice: I´m using java syntax, Parameter is from type Problem, return value is Language)cheers,AndreasLike said, it is save to say that Java will not (and maybe never) disapear. Also it will remain an leading choice for Enterprise Computing, like to descripted.
    Did you read what I said? I'm being pragmatic about what solves REAL PROBLEMS RIGHT NOW, not gawking at the shiny new toys. I KNOW Java solves these problems right now. Everything I've read says Ruby DOES NOT SOLVE these problems right now (especially since there doesn't even seem to be a stable deployment environment for it). In what way am I being a Java fan-boy?

    Apparently, if you don't agree that ROR is the next, best, cutting, edge thing, you are tacitly a fan-boy.

    However, if you agree with Bruce, then you are admitted to the cutting edge club. ;-)
  63. Don´t blame - learn !!![ Go to top ]

    My response was based on this sentence of yours:
    Bruce, This is the crap that pisses people off... "If you were as out ahead of the curve as I am you'd understand, but since you're stuck back in the pack..." Please. Can't you accept that some of us, while understanding that Java isn't the be-all end-all and won't be the best tool forever, also think that RoR is a BAD IDEA, not merely for large enterprise applications, but also for smaller data-driven web apps?

    I agree that my response, which you quoted was a little bit nasty, sorry for that :)

    Read my forther responses on that, there I clearify what I mean.
    Did you read what I said? I'm being pragmatic about what solves REAL PROBLEMS RIGHT NOW, not gawking at the shiny new toys. I KNOW Java solves these problems right now. Everything I've read says Ruby DOES NOT SOLVE these problems right now (especially since there doesn't even seem to be a stable deployment environment for it). In what way am I being a Java fan-boy?

    I´ll be nasty again, because if you dont consider alternativ approaches you are a "fan-boy". Don´t get me wrong, I really like working with Java - in the correct usecases.

    In many cases java is not #1 choise. Guess which language is mostly used for dynamic Pages out there.
    Tip 1) it is not Java
    Tip 2) it starts with "P" and ends with "P"

    cheers,
    Andreas
  64. Don´t blame - learn !!![ Go to top ]

    Guess which language is mostly used for dynamic Pages out there.Tip 1) it is not JavaTip 2) it starts with "P" and ends with "P"cheers,Andreas

    I forgot to mention, that it is #1, because it is really simple to use.
  65. Don´t blame - learn !!![ Go to top ]

    Guess which language is mostly used for dynamic Pages out there.Tip 1) it is not JavaTip 2) it starts with "P" and ends with "P"cheers,Andreas
    I forgot to mention, that it is #1, because it is really simple to use.

    Not in my experience; not for substantial projects. After occasionally struggling with obscure PHP code (with no tools for compile-time checking or refactoring), and trying to deal with conflicts between different versions of Apache and PHP, 'easy' is not a term I would use.

    It is #1 partly because it is easy to get started with, and easy for novices to use, and very easy for companies to host.
  66. Don´t blame - learn !!![ Go to top ]

    Guess which language is mostly used for dynamic Pages out there.Tip 1) it is not JavaTip 2) it starts with "P" and ends with "P"cheers,Andreas
    I forgot to mention, that it is #1, because it is really simple to use.
    Not in my experience; not for substantial projects. After occasionally struggling with obscure PHP code (with no tools for compile-time checking or refactoring), and trying to deal with conflicts between different versions of Apache and PHP, 'easy' is not a term I would use.It is #1 partly because it is easy to get started with, and easy for novices to use, and very easy for companies to host.

    Whether it is part of your experience or not PHP is #1 in dynamic webabbs.

    This this actually not a matter of experience or personal opinion. This is a matter of fact.

    cheers,
    Andreas
  67. Don´t blame - learn !!![ Go to top ]

    Also dont get me wrong. With #1 I mean the most used, not the best possible solution !
  68. Don´t blame - learn !!![ Go to top ]

    My response was based on this sentence of yours:
    Bruce, This is the crap that pisses people off... "If you were as out ahead of the curve as I am you'd understand, but since you're stuck back in the pack..." Please. Can't you accept that some of us, while understanding that Java isn't the be-all end-all and won't be the best tool forever, also think that RoR is a BAD IDEA, not merely for large enterprise applications, but also for smaller data-driven web apps?
    I agree that my response, which you quoted was a little bit nasty, sorry for that :)Read my forther responses on that, there I clearify what I mean.
    Did you read what I said? I'm being pragmatic about what solves REAL PROBLEMS RIGHT NOW, not gawking at the shiny new toys. I KNOW Java solves these problems right now. Everything I've read says Ruby DOES NOT SOLVE these problems right now (especially since there doesn't even seem to be a stable deployment environment for it). In what way am I being a Java fan-boy?
    I´ll be nasty again, because if you dont consider alternativ approaches you are a "fan-boy". Don´t get me wrong, I really like working with Java - in the correct usecases. In many cases java is not #1 choise. Guess which language is mostly used for dynamic Pages out there.Tip 1) it is not JavaTip 2) it starts with "P" and ends with "P"cheers,Andreas

    And how maintainable are those sites? If I need to add integration with other organizations via asynchronous messaging, how do I do it?

    There is definitely a disconnect here if you're going to invoke PHP. Sorry, I don't build bulletin boards or blogs, although the best product I've ever seen in that space (Confluence from Atlassian) is written in Java (and even uses WebWork :-) ).
  69. Don´t blame - learn !!![ Go to top ]

    And how maintainable are those sites? If I need to add integration with other organizations via asynchronous messaging, how do I do it?There is definitely a disconnect here if you're going to invoke PHP. Sorry, I don't build bulletin boards or blogs, although the best product I've ever seen in that space (Confluence from Atlassian) is written in Java (and even uses WebWork :-) ).

    Just to get to uptodate: PHP is #4 @ Sourceforge about 13.000 projects. Java has 18.000.

    There are also messaging projects available, but I cant tell you more on that. Also if you think they dont meet your needs go for Java, PHP is your friend in specific cases not your enemie.

    Also there a dozens of complex PHP app´s out there. You can have a look yourself.
  70. Business A-B-C[ Go to top ]

    Thanks, Paul. Drop me an email some time. In any industry, there are early adopters, pragmatics and skeptics/conservatives. It's a long wave. People riding different parts of the wave can see vastly different things. If you're riding the crest of the wave as I am, and you're concerned about a specialized niche as I am, you can really see a loss of momentum. If you're a pragmatic, you're just starting to notice Rails, and only the front end of the pragmatics are even recognizing Rails or alternatives. But if you are a skeptic/conservative, or if you are an early adopter/pragmatic in another space like mobile, Java is really just getting reved up for you. It really is a massive wave. So in many ways, the replies are understandable. There are just so many unknowns out there. The biggest question in my mind has been can any other wave accumulate enough mass to survive all of the noise? I think I have the answer for one niche, for one customer set...but it's a very important niche.
    Bruce, This is the crap that pisses people off... "If you were as out ahead of the curve as I am you'd understand, but since you're stuck back in the pack..." Please. Can't you accept that some of us, while understanding that Java isn't the be-all end-all and won't be the best tool forever, also think that RoR is a BAD IDEA, not merely for large enterprise applications, but also for smaller data-driven web apps? Some of us feel that hacking together your web app in less time is meaningless compared to the maintenance costs and extensibility to handle more and more features, including integration with other systems and scaling to much larger user-bases. Just because you got stuck doing crappy little CRUD webapps and got bored, don't shake your new shiny toy in our faces and say "See! See! It's much cooler than the tools you've been using!". I'm sure what you were doing WAS boring, but building distributed processing, JMS / Database 2PC systems, and systems integration is sufficiently challenging for a lot of us that we don't really need to try to do it on a platform that can't be deployed reliably.


    Business is driven by requirements, not by illusions.

    You will hardly find customers, who are ready to pay money for the case their webapp "would" have visitors like Amazon / ebay. If that is about to happen, you will be reconsulted to upgrade the system - be happy. If someones is about to buy a car, you will never be able to sell him a space shuttle, for the case he would like to fly to the Moon. Remeber: go for simplicity, the simplest solution is the best....this kind of sentences are repeatet by people who speak from experience - no need to past URL-links.

    A cutomer has clear requirements and needs and will pay as less as possible (!). Let me remind you (I mean everybody in this Thread) that you are not alone. You have competition in here and outside of the Java space.

    Before a customer agrees on a company, he compares various alternatives. The customer will select the company which offers the best price.

    Now, we as experienced developers must select the most suitable solution to the problem - driven by needs and not by idealism. The correct tool could be in some cases Java in other C++, in other Fortan and in other Ruby.

    cheers,
    Andreas
  71. Business A-B-C[ Go to top ]

    A cutomer has clear requirements and needs
    Since when?
    The customer will select the company which offers the best price.
    Sadly, it usually isn't what costs less. And definitely in the long wrong.

    I would say the the customer will select the company which looks to offer the cheapest price.
  72. Business A-B-C[ Go to top ]

    should have been "And definitely not in the long run".
  73. Business A-B-C[ Go to top ]

    A cutomer has clear requirements and needs
    Since when?
    The customer will select the company which offers the best price.
    Sadly, it usually isn't what costs less. And definitely in the long wrong.I would say the the customer will select the company which looks to offer the cheapest price.

    Somehow I had the feeling that such a reply would come.

    I think, you caught the meaning from the complete text. But let me anyhow explain my thoughts in more detail.

    Every customer wants something, what he wants can be expresed as "requirements and needs". Requirements varry from case to case. Sometimes there are more abstract other times more concrete.

    It is the job of you to make sure the customers requirements are complete, if they are not already. I guess we dont need to talk about this, since most people know how do deal with this and since it is not related to the Topic.

    Related to the Topic is the "Price" you offer the customer. The price he has to pay you, to solve his problems / needs.

    The more efficiently you work, the more correct tools you need, the less time it will take -> the less will the price. And that means, choosing the correct Language + correct Tools is significant for winning customers and make them happy.

    cheers,
    Andreas
  74. Business A-B-C[ Go to top ]

    Business is driven by requirements, not by illusions.You will hardly find customers, who are ready to pay money for the case their webapp "would" have visitors like Amazon / ebay. If that is about to happen, you will be reconsulted to upgrade the system - be happy. If someones is about to buy a car, you will never be able to sell him a space shuttle, for the case he would like to fly to the Moon. Remeber: go for simplicity, the simplest solution is the best....this kind of sentences are repeatet by people who speak from experience - no need to past URL-links.A cutomer has clear requirements and needs and will pay as less as possible (!). Let me remind you (I mean everybody in this Thread) that you are not alone. You have competition in here and outside of the Java space.Before a customer agrees on a company, he compares various alternatives. The customer will select the company which offers the best price.Now, we as experienced developers must select the most suitable solution to the problem - driven by needs and not by idealism. The correct tool could be in some cases Java in other C++, in other Fortan and in other Ruby.cheers,Andreas

    I think the disconnect here is that we're not all consultants. We don't all have customers who are looking to get the cheapest solution the fastest. Some of us work for product companies. Many of us work with customers (or stakeholders in our own companies) for whom the Total Cost of Ownership is much more important than having it done next week for 2 pizzas and a sixpack. Many of our companies have been burned by that "let's just get it done now" mentality.

    BTW, I've got friends who've been hired on at a company whos e codebase was built by ThoughtWorks, who are the biggest voices of this type of nonsense. Let's just say they're not thrilled with the code they've inherited.

    I agree that we should choose the best tool for the job, but choose tools for more than the next 2 weeks of work. We've all seen the simple little Access-based VB app that ends up running a large portion of the business, much to that businesses detriment. Hell, I once was consulting at a HUGE financial risk analysis firm in NYC, and they did everything by passing around Excel spreadsheets that someone had whipped up the first time they needed to do something. It was a HUGE problem, but they were stuck there.
  75. I'm out[ Go to top ]

    Thanks, Paul. Drop me an email some time. In any industry, there are early adopters, pragmatics and skeptics/conservatives. It's a long wave. People riding different parts of the wave can see vastly different things. If you're riding the crest of the wave as I am, and you're concerned about a specialized niche as I am, you can really see a loss of momentum. If you're a pragmatic, you're just starting to notice Rails, and only the front end of the pragmatics are even recognizing Rails or alternatives. But if you are a skeptic/conservative, or if you are an early adopter/pragmatic in another space like mobile, Java is really just getting reved up for you. It really is a massive wave. So in many ways, the replies are understandable. There are just so many unknowns out there. The biggest question in my mind has been can any other wave accumulate enough mass to survive all of the noise? I think I have the answer for one niche, for one customer set...but it's a very important niche.
    Bruce, This is the crap that pisses people off... "If you were as out ahead of the curve as I am you'd understand, but since you're stuck back in the pack..." Please. Can't you accept that some of us, while understanding that Java isn't the be-all end-all and won't be the best tool forever, also think that RoR is a BAD IDEA, not merely for large enterprise applications, but also for smaller data-driven web apps? Some of us feel that hacking together your web app in less time is meaningless compared to the maintenance costs and extensibility to handle more and more features, including integration with other systems and scaling to much larger user-bases. Just because you got stuck doing crappy little CRUD webapps and got bored, don't shake your new shiny toy in our faces and say "See! See! It's much cooler than the tools you've been using!". I'm sure what you were doing WAS boring, but building distributed processing, JMS / Database 2PC systems, and systems integration is sufficiently challenging for a lot of us that we don't really need to try to do it on a platform that can't be deployed reliably.

    You're making a bunch of assumptions in your post that I'm not going to address here. I want to talk about the technology adoption curve. If you've read Crossing the Chasm, you know exactly what I mean. You can be pissed off if you want to, but this post has nothing to do with being cool/uncool. It's just marketing theory, and a technology adoption curve, and your place in the technology adoption curve filters your perspective of the technologies you are open to. Your post makes the point nicely. Beyond Java, the interview, and all articles I've written since say that when I advise customers on building the systems you are, I usually choose Java/Spring/and the right persistence framework. That's just not the problem I'm solving most often these days. The place on the adoption curve of my customer necessarily colors my view of the technologies at my disposal. An established company must usually be much more conservative, and relies on much more market maturity. Startups will need to take a little more risk for leverage.

    You can look at these interviews and articles (which are mostly responses to questions by request) as waving a new tool in your face and continue to get pissed off, or you can take them as communication of new ideas that you can take or discard, based on what you know about the author and the problem you're trying to solve.

    So take a deep breath. No one is trying to insult you.
  76. I'm out[ Go to top ]

    You're making a bunch of assumptions in your post that I'm not going to address here. I want to talk about the technology adoption curve. If you've read Crossing the Chasm, you know exactly what I mean. You can be pissed off if you want to, but this post has nothing to do with being cool/uncool. It's just marketing theory, and a technology adoption curve, and your place in the technology adoption curve filters your perspective of the technologies you are open to. Your post makes the point nicely. Beyond Java, the interview, and all articles I've written since say that when I advise customers on building the systems you are, I usually choose Java/Spring/and the right persistence framework. That's just not the problem I'm solving most often these days. The place on the adoption curve of my customer necessarily colors my view of the technologies at my disposal. An established company must usually be much more conservative, and relies on much more market maturity. Startups will need to take a little more risk for leverage. You can look at these interviews and articles (which are mostly responses to questions by request) as waving a new tool in your face and continue to get pissed off, or you can take them as communication of new ideas that you can take or discard, based on what you know about the author and the problem you're trying to solve.So take a deep breath. No one is trying to insult you.

    The assumption YOU make is that this "wave" you're "riding" isn't one that's going to crash into the breakers. I see it as much more likely that a few ideas from RoR will be incorporated into popular Java web frameworks (and hey, I may be the one incorporating them), and Rails popularity will slowly fade as Ruby fades back into being a hobbyist language.

    The arrogance that annoys me, and possibly others, is in assuming that you're an early adopter of the "next big thing" (which we can't see because of this or that), instead of a bored techy playing with a nifty but ultimately pointless new toy.
  77. Early adoption[ Go to top ]

    The assumption YOU make is that this "wave" you're "riding" isn't one that's going to crash into the breakers. I see it as much more likely that a few ideas from RoR will be incorporated into popular Java web frameworks (and hey, I may be the one incorporating them), and Rails popularity will slowly fade as Ruby fades back into being a hobbyist language.

    I make no such assumption. That's the risk of any early adoption, no? In fact, earlier in this thread, I said this:
    The biggest question in my mind has been can any other wave accumulate enough mass to survive all of the noise?


    So even if you like a technology (sounds like you don't), it's still very much a risk/reward equation. I'm in a situaltion where I'm adaptable enough to take the risk, and there's enough momentum and support for me to make that suggestion to customers who are also in a place to take that risk. But I'd never recommend Rails for certain projects.

    As to incorporating a few ideas into Java, I'd very much like to see that happen, and will work to make it happen. I speak with Geert Bevin a couple of times a week on folding the ideas into Rife. I talk with Keith Donald on a regular basis on the work he's doing with WebFlow. I've spoken with other open source leaders about leveraging what's good in Ruby through scripting and JRuby integration. I'm working on an article series with developerWorks that seeks to show Java developers who want to know how some of these ideas are implemented in other languages. So I very much would like to influence Java in this regard.

    So to me it sounds like your issue is with early adopters in general, because early adopters by definition have to take a risk, and by definition must be confident enough to take that risk, and they have to project that confidence.

    Drop me an email if you'd like to continue this discussion.
  78. How you define "Early adopter"?[ Go to top ]

    Reading over your posts, it still isn't clear to me what "early adopter" or "the crest" means. I for one would like to hear the criteria you use to make that classification.

    peter
  79. Early Adoption[ Go to top ]

    It is a misnomer to call it "early adoption"(after thirteen years of birth). It is riding the receding wave. The only place it will take is deep down the ocean.
  80. What defines "the crest"?[ Go to top ]

    Thanks, Paul. Drop me an email some time. In any industry, there are early adopters, pragmatics and skeptics/conservatives. It's a long wave. People riding different parts of the wave can see vastly different things. If you're riding the crest of the wave as I am, and you're concerned about a specialized niche as I am, you can really see a loss of momentum. If you're a pragmatic, you're just starting to notice Rails, and only the front end of the pragmatics are even recognizing Rails or alternatives. But if you are a skeptic/conservative, or if you are an early adopter/pragmatic in another space like mobile, Java is really just getting reved up for you. It really is a massive wave.

    So in many ways, the replies are understandable. There are just so many unknowns out there. The biggest question in my mind has been can any other wave accumulate enough mass to survive all of the noise? I think I have the answer for one niche, for one customer set...but it's a very important niche.

    if you don't mind me asking. How are you defining "the crest". I haven't worked on webapps for over 3 years now, but I definitely don't consider DB driven webapps the crest. What I consider the crest is quite different than someone else. For example, I consider javaspaces, jcache, jxta and grid computing "the bleeding edge". Do these areas apply to most developers? Probably not, but they are areas where innovation is occuring. In the future these technologies will play a larger role in software development as the field continues to mature.

    I used to work on mobile applications and platforms, so I don't consider mobile applications the edge or early adopters. I think the biggest flaw of the pro ROR arguement is that everyone "wants to build apps the ROR way." For cases where someone really wants to build apps the ROR way, then sure it will be very productive.

    Ruby is a good language and it is popular in academic AI field, but the benefits are over-hyped. I also find the anology of "rideing a wave" lame. I don't know about others, but I have no interest in riding "the wave" unless I'm on a surf board in the pacific ocean. I'm also guessing that people are turned off by statements like "if you're riding the crest of the wave as I am."

    development is mostly a human issue and not a technology issue. As I've stated in the past, there are valuable lessons in dynamic languages. Rather than harp on and on, how about contributing to JRuby and help make it reality? Then you have the best of both worlds, Ruby + ROR + Java + J2EE.

    my bias 2 cents

    peter
  81. What defines "the crest"?[ Go to top ]

    Sorry I missed this one. Market adoption, in this context.
  82. What defines "the crest"?[ Go to top ]

    Sorry I missed this one. Market adoption, in this context.

    I don't know about others, but that isn't the impression I got from your posts in this thread and previous TSS threads. Why is market adoption the primary criteria for "the crest"? What if the market is stupid? What if the market is driven by idiotic CTO's who don't know C from Perl? What if market adoption has nothing to do with the inherent qualities of a given technology?

    For 2 decades the business rules sector has been plugging away at business process automation. Over the last 12 months, there's been a lot of hype and buzz about business rules. I've been working in this area for the last 5 years and I believe alot of the hype is complete BS. The big lesson I learned the last 5 years is that business process automation is mostly a human issue. One could argue the same is true of developer productivity.

    just because I work with rule engines, doesn't mean there is a wave or some crest for business process automation. If anything, the hype surrounding business rules only proves that marketing often over promises and under delivers. Just my bias perspective, but I think claiming to be "on the crest" or "an early adopter" comes across as boasting. The fact is, no one knows if ROR really is a wave or not. Maybe in 20 years people can look back and analyze it objectively, but to claim that today is almost like saying, "I'm the messaih. follow me to the promise land."

    Even though I hope Java will adopt some ideas from scripting langauges, I doubt my guesses will amount to anything. If I happen to guess right, then it's sheer luck.

    for what it's worth, I think heated debates are good. it can force people to re-think how things are done.

    peter
  83. I'm out[ Go to top ]

    Thanks, Paul. Drop me an email some time. In any industry, there are early adopters, pragmatics and skeptics/conservatives. It's a long wave. People riding different parts of the wave can see vastly different things. If you're riding the crest of the wave as I am, and you're concerned about a specialized niche as I am, you can really see a loss of momentum. If you're a pragmatic, you're just starting to notice Rails, and only the front end of the pragmatics are even recognizing Rails or alternatives. But if you are a skeptic/conservative, or if you are an early adopter/pragmatic in another space like mobile, Java is really just getting reved up for you. It really is a massive wave. So in many ways, the replies are understandable. There are just so many unknowns out there. The biggest question in my mind has been can any other wave accumulate enough mass to survive all of the noise? I think I have the answer for one niche, for one customer set...but it's a very important niche.

    Okay, so now people who don't agree are conservative. I just listed a litany of things that we do based on our Struts/Spring/Hibernate framework and notice that neither you or Mr. "You don't agree, ergo, you are close-minded" failed to offer any counter points.

    You say that TSS doesn't offer technical content, but choose to engage in what should be embarrasing back patting for guys who are trying to convince people on technical merits.

    I do love the "unknown" arguement. As if everyone was born knowing java and never worked on any other systems or languages.

    Have you even considered that your 4 months scenario makes you an aberration and perhaps you are mistaken?
  84. I´m out[ Go to top ]

    Here are some examples of what's been done by us in SpringI've got, for example, a junior developer who was able to take modify one piece of code that handles searching using Hibernates Query by example, query by criteria, and Spring's convienience classes ALL without really understanding how it works simply by examining the existing code.In a similar vein, I've added caching support to one of our objects using AOP and the open source OSCache. I wrote an interface that uses OSCache for this particular implentation and the caching is configured via Spring.By using the put or get method on the interface contained in that inteceptor one can add caching to one of our Business Object interfaces all without understanding AOP, Spring, or even OSCache.Also, a added a simple interceptor for profiling, in about 2 hrs, that prints for every Business object interface call the name of the object in question, method, execution time, arguments, and memory used before and after the call. By adding this interceptor to the business object definition in our business.xml file, one can add this to any call, again, without fully understanding AOP, Spring, or even the profile interceptor itself.The issue is that once a month an ROR article appears and eventually, someone says that you get all the ROR stuff with the excellent Java software available. Usually, the doubters have never used the stuff, like Spring, that is mentioned.Inevitably, it comes down to value add and whether or not Ruby adds it. I don't think it does. We've been hearing about scripting and dynamic languages replacing static ones for years and it has yet to happen.So when healthy skepticism is offered, and worse, counter-examples, accusations of closed-mindeness abound.Foolishness.I submit that not only does ROR not offer any real innovation, but it doesn't offer any real advantage beyond the current generation of software, like Spring, Hibernate, JDO, etc offers. I further submit that as long as one can come close to matching ROR perceived dev speed, and still scale up to more complex task(something that even ROR proponents say ROR cannot do) ROR will fail to evolve beyond any niche tool that has advocates, but fails to garner any mainstream use.
    I said I wasn't going to do this but a Single google search and what do I find:
    NanoContainer builds on top of PicoContainer the support for several scripting meta-languages (XML, Groovy,Bsh, Jython and Rhyno), AOP, Web frameworks (Struts and WebWork), Persistence (Hibernate) SOAP, JMX, and much more.
    Straight on the PcoContainer website's front page:http://www.picocontainer.org/This is what I mean by closed minds. A massive rant on "what I am doing with Spring. And he hasn't even taken the time to look at the next most popuplar IoC framework in Java - never mind looking at other languages - never mnd realise that IoC containers are just not needed in dynamic languages etc...This is my point. Blind allegiance to what some one else as correctly described as a proprietary technology (Java). Last person I heard ranting like this was a Microsoft VB geek. The truth is that Sun and Microsoft are looking pretty similar these days. Bruce they'll never here you. Just get on with saving your clients time and money (that what they pay you for). These lot have got their egos tied up in a programming language for heavens sake.Now do you think the geek will have the decency to apologise..? Or even admit that he was wrong..? I doubt it.Paul.


    Because a comparable solution exists doesn´t mean it is better. Anyway, how do you know this guy didn´t already evaluate Pico /Nano/Hivemind/..what the heck/ ??

    Personaly I realy support alternative languages to Java. Currently I´m working on a project using JESS, a rulebased-language, which offers in "specific usecases" "significant" advatages to traditional proced.+OO programmng. There are problems you can´t solve without rulebased apporaches, as a trivial example think of a Crossword puzzle, having empty fields and a set of words. Does the given set of words (unordered) match with the Crosswordfields ? Try to solve this in Java or C++ , in Prolog or Jess it is only a single line of code.

    A logic question at this point would be: Why jess and why not a comparable product ?. The reason is that jess can coop. with Java, since it is written completely in Java. You get what I´m saying ? ..... correct, because I feel "comforable", "save" and "productive" using Java, I choosed jess for rulebased-computation and Java for other parts of the App.

    I know that some people will not agree with me at this point, but I think that the majority of the Java Community will only accept Languages which are based on the JVM. The reason is from my perspective obvious: legacy. Even from a econimic perspective (not the geeky one) this offers advantages and encourages managers and bosses to try "somethink" new, since the old stuff could be reused. I think thins is the way a lot of people think.

    And because this JVM based alternatives are available and emerging (Groovy, JRuby, ...), people will hardly go to ruby + ror.

    This is my opinion on this topic.

    cheers,
    Andreas
  85. I´m out[ Go to top ]

    Andreas,

    You need to read the whole thread. I was making a rather mundane point - about the fact that most of us program in several languages already and made the mistake to imply that XML as used with IoC containers such Spring is in fact a component scripting language. Well this was the response:
    They don't call it scripting. AOP definitely has nothing to do with scripting. No offense, but it doesn't seem like you understand IOC, AOP, or Spring, which is why your analogy fails.

    And my response to him in kind:
    No they don't call it scripting... No offence but it doesn't seem that you are capable of opening your mind and thinking for yourself :^)Paul.

    He then followed this with a rant that is too long to quote. The original technical point I was making was lost in a torrent of abuse.

    The facts are:
    NanoContainer builds on top of PicoContainer the support for several scripting meta-languages (XML, Groovy,Bsh, Jython and Rhyno), AOP, Web frameworks (Struts and WebWork), Persistence (Hibernate) SOAP, JMX, and much more.

    As far as I can see, Bruce Tate has only had the courage to say what many people have been thinking for a long while. Java is just another proprietary language much like C# with pretty much the same limitations. For many things there are better alternatives out there.

    The fact that you are running to this guys defence without even understanding the background just goes to prove that the Java Community has denigrated to a similar level of blind faith as the Microsoft Developer Community. Why all this blind allegiance to a proprietary standard? Examine the facts and make an informed decision for yourselves.

    Paul.
  86. I´m out[ Go to top ]

    Java is just another proprietary language much like C# with pretty much the same limitations.

    No, it really isn't. If it was, then I would be happily using C#!

    For me, for at least a while (and I suspect this may last for some time) Java hits a 'sweet spot'. That sweet spot is the combination of free, really effectively cross-platform, multi-vendor, really good performance, easy to develop with (multi-threading and garbage collection built in), and OOP.

    I had been looking for such a language for a very long time. Smalltalk came close for a while, but wrecked its chances for me with vendor incompatibilities and unpleasant pricing for the high performance versions. This is a real shame, as I far prefer Smalltalk to Java in many respects.

    C# loses it because it does not have effective multi-vendor support.

    Sooner or later another language may well hit that 'sweet spot', but for now, for me, and for an increasing number of developers, its Java. For me, it is not some sort of fanatical admiration for the language (although I do have a lot of respect for Sun) - it is a pragmatic choice.

    As for the future - who knows? Ideally, something like JRuby would get finished and include a compiler to Java bytecode so we could use all the high performance and features of the JVM with a fun and flexible language.
  87. I´m out[ Go to top ]

    Hi Steve,

    I understand your reasons for using Java and IMO I feel that they are pretty valid. At least - valid for you (I do not agree with you when it comes to how best to achieve performance - but that is a small point).

    Many others on this thread however are ranting in favour of Java from a position of ignorance - blissful ignorance at that.

    It reminds me of people who use to rant in favour of Visual Basic who had never used anything else.

    Let's deal with some fundamentals. Sun is a business, their primary responsibility is to their shareholders not the Java development community.

    Java is not free. Sun allows you to use a "free" copy of the JVM binary. If you want the source you need to pay, and even then the license comes with all sorts of terms and conditions to ensure that the Java platform remains proprietary to Sun.

    Now nothing is wrong with that. Such a thing as a benevolent dictator does exist - but lets not think that we are the ones in control.

    Microsoft did the same thing when they shipped Visual Basic for $40. Sun Just did one better - by giving Java away for "free". It's all Marketing and PR.

    I'm glad Java meets your "sweet spot" - but lets not forget what Java is at its foundation - just another proprietary programming language enjoying it's time in the Sun.

    Like you rightly say - it well come and go just like everything else.

    Paul.
  88. I´m out[ Go to top ]

    Java is not free.
    If you look contextually at Steve's post, you can see he was talking about free as in money.
    Sun allows you to use a "free" copy of the JVM binary.
    See. You do agree with him. :)
     If you want the source you need to pay,
    Not true. http://www.sun.com/software/communitysource/j2se/java2/download.xml

    and even then the license comes with all sorts of terms and conditions to ensure that the Java platform remains proprietary to Sun.
    Not having scoured the license, I'll go with true.
    Now nothing is wrong with that. Such a thing as a benevolent dictator does exist - but lets not think that we are the ones in control. Microsoft did the same thing when they shipped Visual Basic for $40. Sun Just did one better - by giving Java away for "free".
    And, Sun is not trying to bind you to Windows, or any other platform than Java.
  89. clarifications[ Go to top ]

    Many others on this thread however are ranting in favour of Java from a position of ignorance - blissful ignorance at that.

    The fact that someone disagrees with you doesn't make them ignorant ;-)
    Java is not free.

    Java is free. The language and JVM specifications -- as well as multiple implementations thereof -- are free by many definitions, including Stallman's. Free as in beer. Free as in freedom. Free as in unencumbered.

    In fact, the only right withheld is the use of the "Java" trademark.
    Sun allows you to use a "free" copy of the JVM binary. If you want the source you need to pay, and even then the license comes with all sorts of terms and conditions to ensure that the Java platform remains proprietary to Sun.

    This is completely incorrect.

    I have the source for a dozen different Sun JVM versions, and I've never paid for any of them. I'm even allowed to muck with them and build them and make incompatible versions from them. I just can't call them Java if they aren't compatible.
    Microsoft did the same thing when they shipped Visual Basic for $40. Sun Just did one better - by giving Java away for "free". It's all Marketing and PR.

    There's a few major differences:

    1) Microsoft sued or threatened to sue anyone that made VB clones without paying them. Sun encouraged others to implement the JVM specs.

    2) Microsoft used VB to lock people into Windows. Sun used Java to unlock people from Windows.

    3) Microsoft controls VB. Sun opened up the process of controlling Java to an industry body, the JCP.

    4) Microsoft tightly controls the sources of VB. Sun has shipped the sources for Java from day one.

    5) Microsoft made sure that VB was not portable. Sun made sure that Java was portable.

    6) Microsoft eliminated competition. Sun encouraged competition.

    7) Microsoft sold VB. Sun provided Java for free.

    8) Microsoft changed VB in very incompatible ways. Sun has tried to maintain compatibility.

    etc.
    I'm glad Java meets your "sweet spot" - but lets not forget what Java is at its foundation - just another proprietary programming language enjoying it's time in the Sun.

    Proprietary proprietary proprietary proprietary.

    Whatever.

    The original Java Language Specification included in its grant of license (which was free) the right to implement, including grant of patents.

    What else could you ask for?

    Proprietary you proprietary and proprietary Dalibor proprietary drive proprietary me proprietary nuts proprietary sometimes proprietary by proprietary abusing proprietary the proprietary term proprietary "proprietary" proprietary.

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  90. Java is free. The language and JVM specifications -- as well as multiple implementations thereof -- are free by many definitions, including Stallman's. Free as in beer. Free as in freedom. Free as in unencumbered.In fact, the only right withheld is the use of the "Java" trademark.

    It would be awesome if that was actually true, Cameron.

    Read the fine specification licenses. Taken from http://java.sun.com/docs/books/vmspec/2nd-edition/html/Copyright.doc.html

    "This license allows and is limited to the creation and distribution of clean room implementations of this specification that: (i) include a complete implementation of the current version of this specification without subsetting or supersetting; (ii) implement all the interfaces and functionality of the required packages of the JavaTM 2 Platform, Standard Edition, as defined by SUN, without subsetting or supersetting; (iii) do not add any additional packages, classes, or interfaces to the java.* or javax.* packages or their subpackages; (iv) pass all test suites relating to the most recent published version of the specification of the JavaTM 2 Platform, Standard Edition, that are available from SUN six (6) months prior to any beta release of the clean room implementation or upgrade thereto; (v) do not derive from SUN source code or binary materials; and (vi) do not include any SUN source code or binary materials without an appropriate and separate license from SUN."

    You are not allowed to implement them, unless your implementation is fully compatible with largely unpublished current specs, and passes compatibility tests you are only allowed to 'Read Only', per JCK license. Free as in what exactly do you think that is, Cameron?

    In fact, implementors had to include proprietary verifier code in the compatible implementations, for example, up to J2SE 1.4, so there was no way to have a compatible, open source implementation that would enjoy any of those oh so lovely patent grants, until last year, after 1.5 was released. Little known facts, outside of the community of people actually doing this sort of stuff, so no worries, you can't know everything about everything.

    Unless you are fully compatible and certified, you get nothing, no patent protection, no license to implement the specs, no nothing at all. You can still do it on your own risk, of course, and as long as you're as irrelevant to Sun's business as open source J2SE implementations are (and will be for the forseable future), Sun is not going to care about it.

    If you want to look at what an open standard looks like, look at Sun's patent covenant around Open Office's XML format, and the associated licensing of the OASIS ODF standard. That's a really open standard. Good stuff. Sun has no plans to do something like that for Java, though.

    It makes no business sense for Sun to turn Java into an open standard, that can be implemented freely, royalty and patent-license free by anyone, with verifiable compatibility, and so on, since there is no licensing income for Sun down that road. If Java was an open standard, how long would it last until IBM's JVM came bundled with SWT, for example, and wiped the floor with Sun's RI? Or Microsoft had a J# transparent migration compatibility mode for Whidbey, or worse for Sun, the .NET compact framework? Sun can't open up the standards without losing control, as much as many Sun employees may want that to happen, and they need total control of J2SE in order to be able to make money from it and J2ME.
    I'm even allowed to muck with them and build them and make incompatible versions from them. I just can't call them Java if they aren't compatible.

    You can't build incompatible versions of SCSL'd code, and redistribute those, for example. Similarly, you can only use JRLd code for research purposes. You may not distribute JIULd code freely, etc. Free as in Microsoft Shared Source licensing, really. Rotor is under pretty similar terms.

    There are many more restrictions in Sun's technology licenses, for example prohibiting commercial use for JRL licensed code (i.e. Mustang), beside the trade mark restrictions.

    Let me help you understand Java technology licensing, Cameron. You may want to take a look at the JRL FAQ on http://java.net/jrl.csp . Point 8 reads:

    "8. When do I need to get a commercial license?

    This research license is only for initial research and development projects. If you decide to use your project internally for a productive use, and/or distribute your product to others, you must sign a commercial agreement such as the Java Distribution License (JDL) and meet the Java compatibility requirements."

    And in fact, for the short-sighted developers, like myself, Sun has gone through great pains to make sure that the respective passage in the JRL is in upper case letters:

    "II. PURPOSE.

    Sun is licensing the Technology under this Java Research License (the
    "License") to promote research, education, innovation, and development
    using the Technology. This License is not intended to permit or
    enable access to the Technology for active consultation as part of
    creating an independent implementation of the Technology.

    COMMERCIAL USE AND DISTRIBUTION OF TECHNOLOGY AND MODIFICATIONS IS
    PERMITTED ONLY UNDER A SUN COMMERCIAL LICENSE."

    Get it? Good.

    If you still think Sun would let you distribute modified binaries of their proprietary source code freely, without passing the certification, please go for it, announce it on TheServerside, and we'll see how long it takes for Sun's legal department to shut you down. Remember JDocs.com?

    Sun's business model for Java revolves around being able to sell IP licenses to companies wanting Java support for their platforms, and selling support for that, that's understandable. I don't have a particular problem with that, it's Sun's IP, and Sun has the obligation to their shareholders to at least try to make some money from it. I am happy for them that mobile Java is finally making them some welcome licensing cash. Sun is no Microsoft, for sure. But Sun's business interest is not in being a community charity, either.

    cheers,
    dalibor topic
  91. I am happy for them that mobile Java is finally making them some welcome licensing cash. Sun is no Microsoft, for sure. But Sun's business interest is not in being a community charity, either.cheers,dalibor topic
    Agreed. I've calmed down a bit now. But I did think the point needed to be made. Sun isn't some benevolent Moses leading us all to the promised land. They are just a Software Company, and Java is just a programming language.

    We have to take responsibility for our own futures - that's the real world.

    Paul
  92. Sun isn't some benevolent Moses leading us all to the promised land. They are just a Software Company, and Java is just a programming language.We have to take responsibility for our own futures - that's the real world.Paul

    The real world is that Sun is neither a benevolent prophet nor just another software company. Sun is company that has pioneered many things in IT (and they are also a hardware company). Java is not perfect, but neither is it 'just a programming language'. It is a reasonably high-performance language + a large set of libraries + a platform for general-purpose vendor-neutral portable development and deployment. There have been many attempts at this before, but Java is the first that has really succeeded. That is significant.
  93. Sun isn't some benevolent Moses leading us all to the promised land. They are just a Software Company, and Java is just a programming language.We have to take responsibility for our own futures - that's the real world.Paul
    The real world is that Sun is neither a benevolent prophet nor just another software company. Sun is company that has pioneered many things in IT (and they are also a hardware company). Java is not perfect, but neither is it 'just a programming language'. It is a reasonably high-performance language + a large set of libraries + a platform for general-purpose vendor-neutral portable development and deployment. There have been many attempts at this before, but Java is the first that has really succeeded. That is significant.
    Hi Steve,

    Relax - In the grand scheme of things even the best programming language ever ever is still just a programming language (BTW I'm not saying that Java is the best language ever ever :^)). This comment was meant to be light hearted.

    I've calmed down, so I'm sure you can :^)

    Paul.
  94. This comment was meant to be light hearted.I've calmed down, so I'm sure you can :^)Paul.

    The mood of comments is hard to read, unless stated explicitly, which is why you may have wrongly assumed that I have not been postingly calmly.....
  95. Sun is a good hardware vendor, too[ Go to top ]

    They are just a Software Company, and Java is just a programming language.

    Actually, Sun's a pretty good hardware vendor. Their AMD64 boxes are very, very neat.

    They happen to be a software vendor as well, with mixed success. Some of their software products are free as in freedom, some are proprietary, but available as gratis downloads, depending on the best way they see to monetize the technology they have.

    Nothing wrong with that, in my opinion. I am happy to see them moving more of their stuff to a "free as in freedom" licensing model, and I think a lot of the folks at Sun have done some really good work there to make things like OpenSolaris, and the GPLd SPARC design possible. Cool stuff, and good luck making it as a free software vendor.

    Otoh, it's also obvious that Sun has no interest in moving all of its technology to an open source licensing model, and all of Sun's executives whose interviews I've read have been really careful to point out that the recent rebranding and remaking of the software side of the company as a free software shop specifically excludes the Java technology.

    cheers,
    dalibor topic
  96. Hi Dalibor,

    I figured you'd go for the gusto ;-) .. here's my proof:

    http://www.microsoft.com/net/default.mspx

    http://gcc.gnu.org/java/

    http://www.kaffe.org/

    On the patents issue, I may be plain wrong. I'll have to dig further on that, which I [unfortunately] don't have time to do right now.

    As far as getting for free and mucking with, Sun's license are fine. As far as "free as in freedom" and distributing, the GPL'd implementations are fine. I wasn't implying that it was all from Sun (or even all with their blessing ;-)

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  97. Heh ;)[ Go to top ]

    Hi Cameron,

    thanks for taking it easy! ;)

    I believe that Microsoft and Sun have a patent exchange agreement, since they settled the J2SE(TM) contract violation lawsuit. That would cover any potential problems in CLR vs. JVM(TM).

    Gcj and Kaffe, otoh, are not Java (TM). I am sure the Kaffe website says that in bold font, just to make sure people don't confuse it with the real thing. I maintain Kaffe atm, so I'd notice if it suddendly became a compatible & certified J2SE(TM) implementation, I hope. ;)

    In practice, no commercial J2SE(TM) vendor really cares about the few hundred source code downloads per month Kaffe.org gets, and I believe Kaffe is the most popular one among the free software runtimes for programs written in the Java programming language, to put it in Sun Microsystems(TM) trade mark usage license compliant terms.

    FWIW, Sun gets 20 million downloads of JRE/JDK according to Schwartz. ;)

    It'd be pointless for Sun to pick a fight with the 'just for fun' folks from Kaffe.org, or to perform a ritual suicide as a Unix software vendor by attacking the FSF, who holds the copyrights on gcj. Neither do those projects infringe on Sun's copyrights or licenses for all I know (we tell people to stay the heck away from Sun's code, or click through spec licenses with too restrictive terms before contributing), nor would it make any business sense for Sun to go after open source projects, that at best, bring some form of limited Java execution capabilities to platforms that noone has a commercial interest in paying for a proper J2SE port and certification, and at worst, have no commercial relevance in Sun's (and their licensees') target markets.

    But rest assured, if Oracle, Google, and Tangosol ;) decided to drop a few million dollars into combining the various research forks of Kaffe like Janos (isolates) and Jessica2 (clustering) into one Ueber-VM for Windows, Solaris and Linux that they'd like to sell along with their products, I'd have Sun's lawyers on the phone the next day to make sure that I buy a proper technology license for J2SE 1.5+, enter the JCP family, and do the whole PR love dance. ;)

    cheers,
    dalibor topic
  98. clarifications[ Go to top ]

    Proprietary you proprietary and proprietary Dalibor proprietary drive proprietary me proprietary nuts proprietary sometimes proprietary by proprietary abusing proprietary the proprietary term proprietary "proprietary" proprietary.
    Hmmm. I wonder what it would say if I could play it backwards.

    Thanks for the laugh Cameron (aka A. Kevin Nealon)
  99. Ideally, something like JRuby would get finished and include a compiler to Java bytecode so we could use all the high performance and features of the JVM with a fun and flexible language.

    Uh, no. You can't implement Ruby more efficiently on the JVM than you can do it with a dedicated, native VM. The design of the JVM does not allow for an efficient implementation of languages that are not Java-like. You can't modify the design of the JVM without breaking backwards and migration compatibility. No go.

    Even if you could magically persuade Sun to screw backwards compatibility (which is the major selling point for J2SE licensees, so you'd have to persuade them to give up their licensing revenue as well) and solve the technical problems with Java and the JVM, JRuby would always be behind the 'standard' ruby implementation in terms of features, mindshare and code written for it, because it's not the project that the actual ruby runtime developers are working on.

    That is the main reason why Rails does not run on JRuby today, and most likely won't run on it reliably in the future. There is as little point for the authors of Rails to limit themselves to the incomplete feature set of JRuby as is for your average Java enterprise developer to limit himself to the feature set of Kaffe, Harmony or whatever.

    cheers,
    dalibor topic
  100. Ideally, something like JRuby would get finished and include a compiler to Java bytecode so we could use all the high performance and features of the JVM with a fun and flexible language.
    Uh, no. You can't implement Ruby more efficiently on the JVM than you can do it with a dedicated, native VM.

    You are disagreeing with a point I didn't make. I didn't say you could implement Ruby more efficiently on the JVM than on a dedicated, native VM. A dedicated native VM would be nice. I just have a lot of doubts that a one is ever going to appear; at least in the near future. There has been a lot of talk about native high-performance VMs for languages such as PERL and Ruby. A lot of talk for a long time, but these projects seem stuck in Beta hell. Parrot (as at 8th Jan) is at version 0.4.x YARV (a Ruby VM) is at 0.3.x.

    Even when you get a fully-function VM, getting it to run really high performance can take a phenomenal amount of work; especially cross-platform.

    Meanwhile, with all its disadvantages, there is the JVM, which is here, free, cross-platform, high-performance (for many applications) and works.
  101. You are disagreeing with a point I didn't make. I didn't say you could implement Ruby more efficiently on the JVM than on a dedicated, native VM.

    Indeed, I'm sorry about that. If you are coming to FOSDEM, let's have beers there :)
     A dedicated native VM would be nice. I just have a lot of doubts that a one is ever going to appear; at least in the near future. There has been a lot of talk about native high-performance VMs for languages such as PERL and Ruby. A lot of talk for a long time, but these projects seem stuck in Beta hell. Parrot (as at 8th Jan) is at version 0.4.x YARV (a Ruby VM) is at 0.3.x. Even when you get a fully-function VM, getting it to run really high performance can take a phenomenal amount of work; especially cross-platform.Meanwhile, with all its disadvantages, there is the JVM, which is here, free, cross-platform, high-performance (for many applications) and works.

    Well, the trouble with the JVM is that it makes no sense for people implementing those languages to tie themselves to Java bytecode, since the JVM-based implementations are always going to be orders of magnitude slower, in general, than native ones, no matter how great some proprietary JVM implementation is.

    They can't embrace and extend those JVMs to make them work better, since those high-performance, working, kick-ass JVM implementations are not open source, and are not going to be open source for the forseable future, because that makes no business sense to Sun. We can't have it both ways, prasing Sun for being a 'benevolent dictator' that prevents others from embracing and extending our beloved high-performance JVM, and at the same time condemning Sun for being a 'non-benevolent dictator' that prevents others from embracing and extending our beloved high-perfomance JVM.

    So in the long run, the best proposition for alternative language developers is to either target something like LLVM, gcc, parrot, or write their own with vmgen, etc. That turns out to be what most of them are doing, with afaict much better success than those implementations that are JVM based.

    Seriously, it is much more fun, and effective use of a researcher's time to simply write a better gc, or interpreter, or jit for their favourite language and platform, when it turns out to be necessary, than to have to spend time dealing with the whole NDA-ridden JCP setup, Java technology licensing restrictions, and trying to push through changes there.

    It took 10 years to get generics halfway reasonably done and dragged through the JCP. Why would ruby runtime developers wait 10 years to get the changes they need into the JVM? They can write their own high-performance runtimes in the same time, without having to care about the JVM source code's commercial usage restrictions, and similar things that make hacking on the JVM RI unattractive, unless someone pays you for it.

    cheers,
    dalibor topic
  102. I´m be back[ Go to top ]

    Andreas,You need to read the whole thread. I was making a rather mundane point...

    Sorry for the missinterpretation, I think the thread has gotten to large, to trace every single response - time´s money :)

    For many things there are better alternatives out there.The fact that you are running to this guys defence without even understanding the background just goes to prove that the Java Community has denigrated to a similar level of blind faith as the Microsoft Developer Community. Why all this blind allegiance to a proprietary standard? Examine the facts and make an informed decision for yourselves. Paul.

    Reading responses carefully counts for everybody. Re-read what I´ve written and re-judge.

    Andreas
  103. I´m be back[ Go to top ]

    Andreas,You need to read the whole thread. I was making a rather mundane point...
    Sorry for the missinterpretation, I think the thread has gotten to large, to trace every single response - time´s money :)
    For many things there are better alternatives out there.The fact that you are running to this guys defence without even understanding the background just goes to prove that the Java Community has denigrated to a similar level of blind faith as the Microsoft Developer Community. Why all this blind allegiance to a proprietary standard? Examine the facts and make an informed decision for yourselves. Paul.
    Reading responses carefully counts for everybody. Re-read what I´ve written and re-judge.Andreas
    Yes, Andreas,

    I apologise, your response was well reasoned. I guess I'm just peeed. I think I should really go :^).

    Paul.
  104. I'm out[ Go to top ]

    The truth is that Sun and Microsoft are looking pretty similar these days. Bruce they'll never here you. Just get on with saving your clients time and money (that what they pay you for). These lot have got their egos tied up in a programming language for heavens sake.Now do you think the geek will have the decency to apologise..? Or even admit that he was wrong..? I doubt it.Paul.

    Yet again, I feel you are putting far too simple an interpretation on a complex situation.

    Statements like "open source helps innovation", "Sun is similar to Microsoft" or "People don't understand what Bruce Tate is saying" only apply in a limited way.

    Some of us agree with a lot of what Bruce says, but feel that the way certain points are emphasised or generalised is mistaken. (For example, I have no doubt that something will replace Java, but I disagree with the implied timescale). And I hope that for some of us, it is a friendly disagreement, and I agree that some of the posts here have been unnecessary and unpleasant.

    Oh, and having dealt with Sun and Microsoft since they both started, I can say that (to me) they are looking the same :) Maybe when Microsoft releases an open source version of Windows, I may start to agree with you :)
  105. I'm out[ Go to top ]

    , I can say that (to me) they are looking the same :)

    Please forgive the missing 'not'!!
  106. I'm out[ Go to top ]

    I said I wasn't going to do this but a Single google search and what do I find:
    NanoContainer builds on top of PicoContainer the support for several scripting meta-languages (XML, Groovy,Bsh, Jython and Rhyno), AOP, Web frameworks (Struts and WebWork), Persistence (Hibernate) SOAP, JMX, and much more.
    Straight on the PcoContainer website's front page:http://www.picocontainer.org/

    I did a google search too and found no mention of scripting.

    http://www.google.com/search?hl=en&hs=kLr&lr=&client=firefox-a&rls=org.mozilla:en-US:official&oi=defmore&defl=en&q=define:XML
  107. I'm out[ Go to top ]

    Here are some examples of what's been done by us in SpringI've got, for example, a junior developer who was able to take modify one piece of code that handles searching using Hibernates Query by example, query by criteria, and Spring's convienience classes ALL without really understanding how it works simply by examining the existing code.In a similar vein, I've added caching support to one of our objects using AOP and the open source OSCache. I wrote an interface that uses OSCache for this particular implentation and the caching is configured via Spring.By using the put or get method on the interface contained in that inteceptor one can add caching to one of our Business Object interfaces all without understanding AOP, Spring, or even OSCache.Also, a added a simple interceptor for profiling, in about 2 hrs, that prints for every Business object interface call the name of the object in question, method, execution time, arguments, and memory used before and after the call. By adding this interceptor to the business object definition in our business.xml file, one can add this to any call, again, without fully understanding AOP, Spring, or even the profile interceptor itself.The issue is that once a month an ROR article appears and eventually, someone says that you get all the ROR stuff with the excellent Java software available. Usually, the doubters have never used the stuff, like Spring, that is mentioned.Inevitably, it comes down to value add and whether or not Ruby adds it. I don't think it does. We've been hearing about scripting and dynamic languages replacing static ones for years and it has yet to happen.So when healthy skepticism is offered, and worse, counter-examples, accusations of closed-mindeness abound.Foolishness.I submit that not only does ROR not offer any real innovation, but it doesn't offer any real advantage beyond the current generation of software, like Spring, Hibernate, JDO, etc offers. I further submit that as long as one can come close to matching ROR perceived dev speed, and still scale up to more complex task(something that even ROR proponents say ROR cannot do) ROR will fail to evolve beyond any niche tool that has advocates, but fails to garner any mainstream use.
    I said I wasn't going to do this but a Single google search and what do I find:
    NanoContainer builds on top of PicoContainer the support for several scripting meta-languages (XML, Groovy,Bsh, Jython and Rhyno), AOP, Web frameworks (Struts and WebWork), Persistence (Hibernate) SOAP, JMX, and much more.
    Straight on the PcoContainer website's front page:http://www.picocontainer.org/This is what I mean by closed minds. A massive rant on "what I am doing with Spring. And he hasn't even taken the time to look at the next most popuplar IoC framework in Java - never mind looking at other languages - never mnd realise that IoC containers are just not needed in dynamic languages etc...This is my point. Blind allegiance to what some one else as correctly described as a proprietary technology (Java). Last person I heard ranting like this was a Microsoft VB geek. The truth is that Sun and Microsoft are looking pretty similar these days. Bruce they'll never here you. Just get on with saving your clients time and money (that what they pay you for). These lot have got their egos tied up in a programming language for heavens sake.Now do you think the geek will have the decency to apologise..? Or even admit that he was wrong..? I doubt it.Paul.

    Right. I provide clear examples to back my point, and you attack personally. The last refuge of the incompetent. I hope you are Bruce keep advocationg ROR. When the time comes to bring in someone to clean the mess, like I've done with VB projects, I'm on the case!
  108. Ruby will be dead before Java...[ Go to top ]

    <blockquoteThey don't call it scripting. AOP definitely has nothing to do with scripting. No offense, but it doesn't seem like you understand IOC, AOP, or Spring, which is why your analogy fails.
    No they don't call it scripting... No offence but it doesn't seem that you are capable of opening your mind and thinking for yourself :^)Paul.
    Right. I don't call Spring scripting. They don't call it scripting. The only person I've seen refer to Spring as something that does scripting is you to support what is, IMO, a poor analogy. I accept the fact that disagreement with you equates to your definition of closed-mindeness.
  109. Ruby will be dead before Java...[ Go to top ]

    I agree with Bruce on this one. Why use the same language that you use to write device drivers to build enterprise applications? It just doesn't make sense. In the long run different languages will be used for different things, trading performance and accessibility.
    I know this may sound like an extreme position, but I think it can make sense (well, perhaps not device drivers, but certainly high-performance things like databases). If a language is efficient enough to write such things, you have a guarantee that it will cope with whatever you throw at it. You know that it will run well multi-threaded. You know that it can efficiently handle memory.
    So why not use a dynamic domain specific business language to script together Java components?
    Because I have so often seen the horrors than can result from this; bad decisions can be made about where the dividing line should be between languages.

    Indeed! A job I left some time ago was taken over by a guy who added on to my java code with a mixture of csh, C, and perl because it was "easier".

    He's gone now and his stuff is far more difficult to maintain than the stuff I wrote(according to the people there).

    Anyone can hack out stuff quickly. The real skill is in writing it to be maintainable and extendable and NOTHING I've read from the ROR advocates leads me to believe this is happening, is important, or even a goal.
  110. Ruby will be dead before Java...[ Go to top ]

    I think this post is a pretty good indication of where we've come. So is it a good idea to write databases, middleware and applications in the same language?
    He wasn't saying that it should be done. But rather that it can be done.
     That's the heart of the issue to me. I've decided that it's not, after coding applications in Java for 10 years.
    After years of doing things in different languages and trying to get them to work together, I think it is best to do as much as possible (this requires thinking/experience) in your core language.

    The SOA-type architectures will enable the heavy lifting and the light applications on top to be written in different languages.
    Depends on how the SOA is done. The typical SOAP SOA though, from my experience, requires a lot of duplication of effort. Which seems to me to fly in the face of the RoR DRY. :)
  111. Ruby will be dead before Java...[ Go to top ]

    He wasn't saying that it should be done. But rather that it can be done.
    After years of doing things in different languages and trying to get them to work together, I think it is best to do as much as possible (this requires thinking/experience) in your core language.

    Exactly.
  112. Err[ Go to top ]

    Bruce Tate is, for all intents and purposes, one of the stupidest people in Java.

    The reason that Java is screwed is that people like him can actually succeed. Bruce is one of those guys (a bit like Jason Hunter, while we're dropping names) who thinks that writing a book means that his opinion is worthwhile and should be taken seriously for all eternity.

    The real shame here is that tss would invite someone like this to TSSJS. It does lend credit to the argument that TSS is not really about java developers, but about traffic and trying to press the right buttons.

    Brucey has already made his point, and gotten a freebie off of tss by having his previous deranged rantings highlighted, how often will this happen? What next, 'Toilet Bruce Used Found to Contain Ruby Shaped Log'?

    Tell you what Brucey, if you think java is so dead, why don't you leave javaland forever, and stop annoying us with your pathetic attempts at selling more of your tawdry, tedious, and terminally boring books?

    As for the JCP being ineffective, I suggest you point that out to the billions and billions of dollars tied up in application server vendors (including open source ones), jdbc drivers, jta, servlets, jsp pages, messaging services, j2se, j2me, and frameworks and libraries built on such (including your precious open source junk). Perhaps you could replace all of that with a quick tug and stroke of DHH, but I suspect most people would find that a surprising, not to mention perplexing decision.
  113. Err[ Go to top ]

    Bruce Tate is, for all intents and purposes, one of the stupidest people in Java.The reason that Java is screwed is that people like him can actually succeed. Bruce is one of those guys (a bit like Jason Hunter, while we're dropping names) who thinks that writing a book means that his opinion is worthwhile and should be taken seriously for all eternity.The real shame here is that tss would invite someone like this to TSSJS. It does lend credit to the argument that TSS is not really about java developers, but about traffic and trying to press the right buttons.Brucey has already made his point, and gotten a freebie off of tss by having his previous deranged rantings highlighted, how often will this happen? What next, 'Toilet Bruce Used Found to Contain Ruby Shaped Log'?Tell you what Brucey, if you think java is so dead, why don't you leave javaland forever, and stop annoying us with your pathetic attempts at selling more of your tawdry, tedious, and terminally boring books?As for the JCP being ineffective, I suggest you point that out to the billions and billions of dollars tied up in application server vendors (including open source ones), jdbc drivers, jta, servlets, jsp pages, messaging services, j2se, j2me, and frameworks and libraries built on such (including your precious open source junk). Perhaps you could replace all of that with a quick tug and stroke of DHH, but I suspect most people would find that a surprising, not to mention perplexing decision.


    Ah, here is Hani and his negativity:-) As much as I dislike reading his (Hani's stuff), this one actually makes sense, and wow, no perverted jokes? Man are you feeling OK?
  114. Err[ Go to top ]

    Bruce Tate is, for all intents and purposes, one of the stupidest people in Java.The reason that Java is screwed is that people like him can actually succeed.
    I won't address the personal stuff, beyond this, Hani. My wife and daughter found your writeup on the bile blog when they were just googling for her dad's name. Not cool. Do you have kids? Are you married?

    But it does depend on what you want to do, doesn't it? If you're building hardcore enterprise apps with JTA and 2pc, I look like an idiot to you. If you're doing what most projects do with a language, just web-enabling a relational database with moderate scale, you may like the books and ideas a little better.
    As for the JCP being ineffective,

    The JCP *is* inneffective for the most part. EJB 1.x, 2.x were both fiascos. The logging mess was completely avoidable. Dog Lea's concurrency tools got it right...establish standards based on experience. That's the way we standardize languages and interfaces elsewhere, but for the most part, the JCP has not advanced Java as far as the open source movement in recent years.
    I suggest you point that out to the billions and billions of dollars tied up in application server vendors (including open source ones), jdbc drivers, jta, servlets, jsp pages, messaging services, j2se, j2me, and frameworks and libraries built on such (including your precious open source junk).

    How much of the app server stuff in WebSphere and WebLogic in the early days was based on C++? Yet it all advanced the state of the art in Java. I can think of a lot of ways to leverage those investments from within Ruby. If Sun were to move things toward being a platform rather than jsut a language, we'd see more projects like Jython that could leverage the capabilities of the JVM. They are already moving in that direction, with the JSR's behind Groovy and dynamic language support.

    JRuby might get there anyway. You can certainly use it to drive your testing today, and live products already use it for things like scripting. If you're looking for coarse-grained integration, the Ruby web services stuff is already pretty good, ad REXML is incredible. But I wouldn't do everything in Ruby, though I do think we're at a similar point to 1996, when people were saying that Java would never run on a server, and applets were toys. You wouldn't have moved away from BEA to run your distributed transactions on Java then, but still, some people saw the writing on the wall. C++ is still a healthy language, but the state of the art usually advances somewhere else.
  115. Err[ Go to top ]

    Regarding the personal stuff, if you're going to stand up and know you'll say things that are controversial, then the intarweb being what it is, it's not a huge leap of imagination to realise that someone somewhere will be annoyed. Don't like it? Play it safe then and hide in anonymity.

    You're right in that it does depend on what you're trying to achieve. Hell, php is a great solution for many problems, as are perl, ruby, c#, VB.net, etc etc. Duh, horses for courses. Are you making this clear in your cheerleading? Saying that java is dead for example to me says that you're just after glamour and bling. If you mean what you said about RoR being appriopriate for some things, then I fail to see how you get from there to 'java is dead'.

    The JCP has made its fair share of mistakes. I note the lack of mention of ejb3 in your list of JCP fiascos. Or of JSP, servlets, JDBC, JMS, JTA, and others. Doug Lea's concurrency is part of the JCP process, java.util.concurrent is the result of that; taking community stuff and formalising it. Are you saying it should have never gotten into the JDK?

    I agree that specs should evolve from existing best practices on the whole, with specifications formalising what people have proven to be 'the way forward'. Don't you think that's happening aplenty currently?

    See despite saying that, you also bitch about lack of innovation. JDK5 includes a lot of 'innovations'. Annotations for example are pretty powerful and handy, once you grok them. These didn't really come from the 'community', they came from the expert group.

    So I fail to see how Java lacks either innovation or community driven specs. It's very easy (trust me, it's my speciality) to find exceptions, and be able to point and laugh at some small aspect that flouts the general rule and hold it up as a trend, but leave that sort of bullshit pulpit thumping to the experts, if you want to be taken seriously and not have people write mean things about you.

    Finally, yes the JCP does move slowly. Care you to find me specifications that move significantly faster? I'm sorry but some random norwegian 20something obnoxious loudmouth does not a spec make. Maybe you're just trying to overcome some kind of midlife crisis by hero-worshipping someone younger and 'cooler'.

    Your argument is I'm sure that specifications don't matter. Sure, they don't matter to people like you who spend all their time 'just web-enabling a relational database with moderate scale', but they matter a lot more to companies who don't get all their work done by consultants who pop in and out for 3 months, and care about old fashioned ideas like sustainability, maintenance, industry support, mindshare, and some measure of future proofing.
  116. Err[ Go to top ]

    but they matter a lot more to companies who don't get all their work done by consultants who pop in and out for 3 months, and care about old fashioned ideas like sustainability, maintenance, industry support, mindshare, and some measure of future proofing.

    Wow, now that's what I call a post. Is there anyone left from the "Hani-Suleiman-has-been-elected-to-the-JCP: WTF???" group that wants to make jokes out of it?
  117. Err[ Go to top ]

    Regarding the personal stuff, if you're going to stand up and know you'll say things that are controversial, then the intarweb being what it is, it's not a huge leap of imagination to realise that someone somewhere will be annoyed.

    Are you married? Have kids?
  118. Err[ Go to top ]

    Awe crap. First Hani gets elected to the JCP, and now I find myself agreeing with him. What next? Men on the moon?

    Frankly, I'm tired of these old windbags (Taters, includes), spouting about the wonders of RoR and their perceived suckiness of Java. There is simply just way too much noise coming from your side of the room over a quasi-scripting language.

    Aside from the large amounts of oxygen you guys are sucking up, its evident to everyone in the room that:

    a. TSS posts this garbage to increase traffic and their ad revenue. +1, for being a tabloid, guys.
    b. The old windbags can't build a community based on the merits of RoR alone, and so must find a target fish to suck a community from. You're the remorrah of the Java community. +1, on sucking.
    c. You've tapped out your careers in the java space and are moving on to, what you hope will be, another language that will allow you to spew endless amounts of books and speeches. +1, on the profit motive.

    So take your RoR, your hot-air marketing, your stapler, and go away, please. Let the rest of us continue with our sucky language and we'll all agree to laugh at each other from afar. ;-)

    STAY METAL!
    Roy Russo
  119. Err[ Go to top ]

    Your argument is I'm sure that specifications don't matter. Sure, they don't matter to people like you who spend all their time 'just web-enabling a relational database with moderate scale', but they matter a lot more to companies who don't get all their work done by consultants who pop in and out for 3 months, and care about old fashioned ideas like sustainability, maintenance, industry support, mindshare, and some measure of future proofing.

    Yes, nicely put.

    I cut my OO teeth on Apple & Tektronix Smalltalk two decades ago, and know its advantages and disadvantages. Ruby looks like it it is the triumphant reinvention of Smalltalk.

    Smalltalk is a wonderful scripting environment, but it is a right royal pain in the backside for someone that is trying to extend/modify another average engineer's codebase.
  120. Err[ Go to top ]

    Regarding the personal stuff, if you're going to stand up and know you'll say things that are controversial, then the intarweb being what it is, it's not a huge leap of imagination to realise that someone somewhere will be annoyed. Don't like it? Play it safe then and hide in anonymity.

    Yes, but you don't have to personally attack people, this is the lowest a person will ever go in their life. Actualy, it usualy can be traced back to a lacking of something on your behalf, for which you must make up by attacking people.
    Your argument is I'm sure that specifications don't matter. Sure, they don't matter to people like you who spend all their time 'just web-enabling a relational database with moderate scale', but they matter a lot more to companies who don't get all their work done by consultants who pop in and out for 3 months, and care about old fashioned ideas like sustainability, maintenance, industry support, mindshare, and some measure of future proofing.

    +1

    Specs matter alot, and until Ruby has anything similar to JCP and/or commercial support, no large company will truly embrace it and bet it's IT on it.

    Ilya
  121. Err[ Go to top ]

    The true strength of Java is it adapts to changing conditions. Ten years from now, it will still be called Java, but it may be unrecognizable compared to today.
    I think this comment nails it. Java is a Brand. It is the first language (Well maybe VB beats it) to be a brand. IBM, BEA, Sun, etc. all have a stake in Java succeeding as a brand. Look back at the Ford Mustang. Nobody in their right mind would say that the Mustang is dead. it is alive and well, but certainly not in the form it was in 1980. Java (at least within the realm of the JCP) is no longer a place for innovation. Hopefully they learned that lesson with EJB 1. However I think it can still be a body for bringing the best of other languages into the Java brand.

    I think it is premature to label java as dead/dying, however I think it is fair to say that Java is no longer the place to explore the bleeding edge. Java will likely remain prominent for the next 30 years, but the new ideas will come from outside its bounds instead of from within.
  122. Err[ Go to top ]

    About 6 1/2 years ago a senior IBM Websphere architect - part of the development team said told me that Java is the byte code as far as IBM was concerned. In other words, any form of expression that could be translated into Java byte code was Java to them. XSLTC comes to mind.
  123. If you mean what you said about RoR being appriopriate for some things, then I fail to see how you get from there to 'java is dead'.

    I think "Java is Dead" is the wrong sentiment. Java is very vibrant. Is there a more vibrant community than this one?

    Ruby can be emerging without Java being dead. (I use the same sentiment about Struts, i.e., "Struts is Dead". I was wrong.)

    RoR for some folks:
    That said, Bruce does make some good points, and it is likely the case that RoR is good for some apps as even Hani seems to admit. I have never used RoR. I remain open-minded, but it is not high on my priority list. I guess what I am saying is that I am not convinced that RoR is the way to go. I remain open-minded but skeptical.

    RoR not for everyone (RoR over-hyped):
    I have several friends and business partners who have tried RoR and it did not work out well for their application. They won't be writing blogs about it, as you could imagine the shrill response of the RoR fan club. I feel the hype around RoR is fairly large and loud.

    The team that I am working with now created a framework based on Facelets, AOP (heavy use of AOP, AspectJ and Spring AOP), JSF, Spring and Hibernate. We can create a simple database web application in a fraction of the time it use to take with a fraction of the code. It is all Java based. We are in the process of getting permission to write a white paper. This framework has built in support for pagination, filtering, etc. etc. And, you can augment with standard JSF, and Java. (Like RoR this framework is not for Amazon.com, but it fits a lot of web application nicely). Also since we are built on top of Hibernate we can easily add caching. Since we are using AOP, we can easily add just about anything really (IMHO).

    (I just did a big presentation on it yesterday. I even combed my hair both of them. ).

    RoR style apps possible:
    With Java you have choice, and the RoR style frameworks are possible (I think). I'll have a lot more to say about this in the future.

    Personal attacks:
    BTW I don't agree with the personal attacks. Bruce has an opinion that is different than mine. I don't feel threatened by that.

    There are two forms of bragging. One form is when you declare how great you are. The other form is when you constantly try to lower other people to make yourself greater in comparison. Neither form is nice. I prefer the first to the latter. Attack the technology not the people. And, remember your future employer may read your post.

    If I was working on a Java project, I'd be happy to work with Bruce Tate. I don't have to agree with him about everything.
  124. Err[ Go to top ]

    Annotations for example are pretty powerful and handy, once you grok them. These didn't really come from the 'community', they came from the expert group.

    Hani, I agree with you on this particular bile, but I thought the annotation trend was started (or at least brought to the spotlights) by XDoclet (so, by the "community"). Am I wrong here?
  125. Annotations[ Go to top ]

    Annotations for example are pretty powerful and handy, once you grok them. These didn't really come from the 'community', they came from the expert group.
    Hani, I agree with you on this particular bile, but I thought the annotation trend was started (or at least brought to the spotlights) by XDoclet (so, by the "community"). Am I wrong here?
    Kind of. The popularity of XDoclet was certainly a good indication that this feature was needed, but we didn't take much inspiration from the XDoclet annotations themselves, simply because they are Javadoc-based and therefore, not really relevant to what we were trying to accomplish.

    Windows annotations were a big source of inspiration and I battled for a while to actually follow their syntax ([Test]), but I was eventually voted down and we went with the '@' notation, which -- in hindsight -- looks better to me now.

    --
    Cedric
    TestNG
  126. Annotations[ Go to top ]

    The most critic process are coded in cobol running on Z/OS, I feel that every day java/j2ee is more complex ... so my question is .. the customers are needing a so complex languaje ?
  127. Err[ Go to top ]

    Regarding the personal stuff, if you're going to stand up and know you'll say things that are controversial, then the intarweb being what it is, it's not a huge leap of imagination to realise that someone somewhere will be annoyed. Don't like it? Play it safe then and hide in anonymity.

    Sorry for waiting a couple of days to post this. I was very much in doubt wether to get involved in this war of turd-tossing.

    So you are saying that you will happily try to kill off anyone who doesn't agree with you by being obnoxious - by yelling louder?

    There are two ways to deal with criticism. One is by rejecting it. Another is to try to find the basis for the criticism and try to figure out how to make the comments by redundant.

    I am terribly disappointed that someone involved with the JCP feels he has to resort to describing the output of his opponents on the porcelain throne instead of being constructive about the feedback.

    I have been following Bruce for a while. I don't agree with everything he says, and his comments on weakly typed languages applied to my world doesn't make sense. I also think he is a bit weak on JDK 5 features. I said this to his face when he was in Norway last year.

    However, you just convinced me that Bruce's comments on the JCP are valid.

    - random norwegian 30something obnoxious loudmouth
  128. Err[ Go to top ]

    RoR: Does the "effectiveness" of RoR mostly come from the pretty scripting language or the framework? From my intensive 15 minute study it appears much of RoR's productivity comes from limiting the config by choosing sensible defaults. Seems to me the framework could be copied and the scripty parts could be handled with, well a JVM-compatible scripting language. This could be made easier (fingers crossed) with the scripting hooks provided by Mustang.

    I know this comes from our current political climate but it is possible (and productive) to criticize something without hating it. I do think it is goofy to think Java the platform is headed for the back burner right now when so much activity is still present. I think it is more interesting to ask if "standardized" Java is becoming less relevant.

    Maybe the Java community is moving toward getting it right: Have a bunch of competing open-source projects try to solve a problem. Take the best ideas and evolve a standard. Isn't that how EJB 3.0 was hatched?
  129. I've been going through Ruby, enjoy it, like it better then Python, never really dug PHP. That being said, I indeed came up as a Cobol programmer, and there are still lots of them around, then I became a Java programmer and that became my main bag. I'm doing RoR a bit out of fear that I'm going to become some of these folks who still cling to Cobol, and refuse to pick up a book, etc...I know some. So in some ways, you have to follow the buzz and chase the shiney objects. But my recent experiences really are a caution to look at a point case (web-to-db) as an arguement about the demise of a general language, which I would assert Ruby is not...at least not yet, and by a long shot.

    So I'm cranking out web apps using J2EE, and we get re-organized...I had to spin up really fast on FIPA agents, Rules engines, Semantic web, mobile development, RFID, and now it's growing into things like JINI and GPS. The point here is that I was able to start a bit higher up the mountain because of the fact that I was adopting a general language as my main bag...so I had JADE, and Jena, and Jess, and Drools, J2ME, etc. The RFID middleware we used was Java, the GPS is low level port stuff using Java, etc...

    I just see all of us presented with weirder and weirder combinations of things as things become smarter, mobile, and more distributed...what the heck is going to replace Java in that space...and why exactly? Certainly not because you have to cast or use a semi-colon...right?

    Anyhow...
  130. I just see all of us presented with weirder and weirder combinations of things as things become smarter, mobile, and more distributed...what the heck is going to replace Java in that space...and why exactly? Certainly not because you have to cast or use a semi-colon...right?Anyhow...

    +1 - Exactly, it wasn't Java the language that was a paradigm shift in the 90's it was Java the platform and its intersection with the internet age.

    I'm not 100% on the history of this but I don't think it is ever the language in a vacum but it is the combination of a language and an external force that made its success.

    C - Personal PCs: Needed a good, reasonably easy fast langauge to write programs back when hardware was expensive.

    COBOL - Needed a good langauge for accounting when mainframes were coming online.

    Ruby's nifty web-app framework is interesting but not going to be the "next big thing".

    My guess is that whatever language makes the next-generation internet features (real-time video, grid computing, security, etc - whatever) easiest to use will be the one to replace Java in the spotlight.
  131. I've been going through Ruby, enjoy it, like it better then Python, never really dug PHP. That being said, I indeed came up as a Cobol programmer, and there are still lots of them around, then I became a Java programmer and that became my main bag. I'm doing RoR a bit out of fear that I'm going to become some of these folks who still cling to Cobol, and refuse to pick up a book, etc...I know some. So in some ways, you have to follow the buzz and chase the shiney objects. But my recent experiences really are a caution to look at a point case (web-to-db) as an arguement about the demise of a general language, which I would assert Ruby is not...at least not yet, and by a long shot.So I'm cranking out web apps using J2EE, and we get re-organized...I had to spin up really fast on FIPA agents, Rules engines, Semantic web, mobile development, RFID, and now it's growing into things like JINI and GPS. The point here is that I was able to start a bit higher up the mountain because of the fact that I was adopting a general language as my main bag...so I had JADE, and Jena, and Jess, and Drools, J2ME, etc. The RFID middleware we used was Java, the GPS is low level port stuff using Java, etc...I just see all of us presented with weirder and weirder combinations of things as things become smarter, mobile, and more distributed...what the heck is going to replace Java in that space...and why exactly? Certainly not because you have to cast or use a semi-colon...right?Anyhow...

    An excellent post. And that's pretty much what I advocate in the book, and in the interview. I do think that the next big thing will probably be a lot of little things. We're going to hit a wall with concurrency soon, as the new parallel processors come out. Ruby is not it in that space, but if you've read much production Java code, a whole lot of it works pretty much by accident, so you know Java's not it in that space either. So do we see a comeback of functional languages, like Erlang? Maybe...

    One niche that I am watching closely is that niche between what you should be doing with a visual basic or php and what you should be doing in Java. That's a space that's several million developers strong. that's been my target market for my books, my courseware, and my consulting practice. RoR has a lot to offer in that space: AJAX, Active Record, the integration, the simplicity, the metaprogramming.

    But my whole point for about a year is that it's about time to start paying attention again. Java *is* showing signs of age. And you need to know what's out there. And you do need to follow the buzz. 200K downloads in under a year is significant. (I think that's about right...)

    So my best guess is that Java is going to undergo a transition period very soon, where it's going to change from the language of choice, in general, to the language of choice for big enterprise. From there? Who knows.

  132. But my whole point for about a year is that it's about time to start paying attention again. Java *is* showing signs of age. And you need to know what's out there. And you do need to follow the buzz. 200K downloads in under a year is significant. (I think that's about right...)
    <
    Is it for putting more buzzword into our resumes or books?

    I think us jumping from one cool thing to another will only hurt software industry in a long term.
  133. An excellent post. And that's pretty much what I advocate in the book, and in the interview.

    It's easy to praise others when they agree with you. :)
    One niche that I am watching closely is that niche between what you should be doing with a visual basic or php and what you should be doing in Java. That's a space that's several million developers strong. that's been my target market for my books, my courseware, and my consulting practice.

    As a former Visual Basic and PHP programmer, I can't say how happy I was to discover Java's potential for building web applications. I agree that VB, PHP and even Perl still have an edge on Java when it comes to RAD, but this edge is disappearing as a result of open-source innovation in the Java space, JCP standards, industry momentum, the evolution of the Java language, and the list goes on.

    <quote>Java *is* showing signs of age.</quote>

    It's called maturity and this is a *good thing*.

    <quote>And you need to know what's out there. And you do need to follow the buzz. </quote>

    I advocate ongoing research but not impatience and hasty decisions. Bruce, it sounds to me like rather than addressing the issues within Java you have thrown the baby out with the bathwater.
  134. I've been going through Ruby, enjoy it, like it better then Python, never really dug PHP. That being said, I indeed came up as a Cobol programmer, and there are still lots of them around, then I became a Java programmer and that became my main bag. I'm doing RoR a bit out of fear that I'm going to become some of these folks who still cling to Cobol, and refuse to pick up a book, etc...I know some. So in some ways, you have to follow the buzz and chase the shiney objects. But my recent experiences really are a caution to look at a point case (web-to-db) as an arguement about the demise of a general language, which I would assert Ruby is not...at least not yet, and by a long shot.So I'm cranking out web apps using J2EE, and we get re-organized...I had to spin up really fast on FIPA agents, Rules engines, Semantic web, mobile development, RFID, and now it's growing into things like JINI and GPS. The point here is that I was able to start a bit higher up the mountain because of the fact that I was adopting a general language as my main bag...so I had JADE, and Jena, and Jess, and Drools, J2ME, etc. The RFID middleware we used was Java, the GPS is low level port stuff using Java, etc...I just see all of us presented with weirder and weirder combinations of things as things become smarter, mobile, and more distributed...what the heck is going to replace Java in that space...and why exactly? Certainly not because you have to cast or use a semi-colon...right?Anyhow...
    An excellent post. And that's pretty much what I advocate in the book, and in the interview. I do think that the next big thing will probably be a lot of little things. We're going to hit a wall with concurrency soon, as the new parallel processors come out. Ruby is not it in that space, but if you've read much production Java code, a whole lot of it works pretty much by accident, so you know Java's not it in that space either. So do we see a comeback of functional languages, like Erlang? Maybe...One niche that I am watching closely is that niche between what you should be doing with a visual basic or php and what you should be doing in Java. That's a space that's several million developers strong. that's been my target market for my books, my courseware, and my consulting practice. RoR has a lot to offer in that space: AJAX, Active Record, the integration, the simplicity, the metaprogramming.But my whole point for about a year is that it's about time to start paying attention again. Java *is* showing signs of age. And you need to know what's out there. And you do need to follow the buzz. 200K downloads in under a year is significant. (I think that's about right...)So my best guess is that Java is going to undergo a transition period very soon, where it's going to change from the language of choice, in general, to the language of choice for big enterprise. From there? Who knows.

    See, I just don't agree. In fact, I think that Java's best times are still in the future. I'm seeing and explosion of productivity that I never experienced. Our deadlines are tight, the customers greedy, and yet we are cranking out code that is of better quality than ever before.

    Over the past 5 projects, our bug list has been simply trivial and our reuse is better than it has ever been.

    I currently uses a program Sage to turn my PC into a HTPC. It is written in Java and has recently exposed an API so plugins are appearing. And places like eBay and Google all have readily available APIs for java.

    No Ruby in sight.

    Heck, maybe I just have a thing for older chicks, but Java is looking pretty hot right now.

    Just what until I get her home...
  135. See, I just don't agree. In fact, I think that Java's best times are still in the future. I'm seeing and explosion of productivity that I never experienced.

    I absolutely agree. There are still millions of C and C++ developers yet to be converted to the benefits of binary portability and garbage collection. Even for those using Java, there are interesting times ahead: There a large number of Java developers still on 1.4 and earlier and yet to use the richness of Java 5.0.

    For those at the cutting edge, Java may look like it is starting to age, but there are few at the cutting edge. My view is that for the majority of developers Java is still a relatively new technology that is replacing legacy systems and ways of working. Java hasn't come close to reaching its peak yet.
  136. Hi Steve,

    Everyone seems to see this thing as Java vs Ruby, but I think this view misses the point. My reading of Bruce's interview was that he was pointing out that standards are best created over time and through experience rather than upfront in a process like the JCP. I agree.

    In this regard the open source community tends to fair a lot better. Good ideas succeed and go on to become standards, poor ideas fall by the way side. Infact the new successful "standards" in Java are all open source.

    So open source languages like Ruby and Squeak are in a much better position to innovate and evolve decent standards that meet the needs of their developer community. I think this is now happening in Java too, but it could be too little too late.

    I'm not sure how the Java Cartel (Sun, IBM, Oracle, BEA etc) will react to the emergence of open source and defacto standards. We will have to wait and see. If they try to protect their existing investments (e.g. Application Servers) then Java could die a slow death under its own weight of flawed API's.

    Paul.
  137. Hi Steve,Everyone seems to see this thing as Java vs Ruby, but I think this view misses the point.

    I agree.
    My reading of Bruce's interview was that he was pointing out that standards are best created over time and through experience rather than upfront in a process like the JCP. I agree.In this regard the open source community tends to fair a lot better. Good ideas succeed and go on to become standards, poor ideas fall by the way side.

    I am not so sure. I think things are far more complicated.
    Infact the new successful "standards" in Java are all open source.

    They are? I think this is too broad a generalization.
    So open source languages like Ruby and Squeak are in a much better position to innovate and evolve decent standards that meet the needs of their developer community.

    Sorry Paul, but I think this is far too idealistic a view. I have seen a richness of ideas in things like Smalltalk (of which Squeak is a great implementation), but I have yet to see any effective standards from the language. Ruby is neat, but hardly standards-based. Indeed, it is suggested by the inventor that future versions of the language may not be backwards compatible. This is fine for innovation, but bad for standardisation.
    I think this is now happening in Java too, but it could be too little too late. I'm not sure how the Java Cartel (Sun, IBM, Oracle, BEA etc) will react to the emergence of open source and defacto standards. We will have to wait and see. If they try to protect their existing investments (e.g. Application Servers) then Java could die a slow death under its own weight of flawed API's.Paul.

    So far the indications are good - with specs like EJB 3.0 showing how open source influences can be adopted.
  138. Hi Steve,
    I understand what you say and things are complex, but we do need to learn the lessons of history. In no other profession do they attempt to determine standards prior to some degree of experimentation and experience.

    Java has suffered from this lack of experiementation. Java has also suffered from a slavish conservatism. New versions of Ruby not being backward compatible in the longer term may turn out to be a good thing.

    There does need to be a balance. The big issue facing Java today is allowing the JVM to properly support dynamic languages. I don't see this happening anytime soon. This will be Java's lost.

    EJB 3.0 is a positive response to developer lead, open source innovation, but will commercial implementations take off? I can't see why they would.

    BTW. A standard is a "standard" if it is generally accepted as such and is common property. Using this definition, open source implementations such as Hibernate qualify as a standard, incidently so does RoR.

    Interesting times ahead I think, and the outcome is by no means certain.

    Paul.
  139. Hi Steve,I understand what you say and things are complex, but we do need to learn the lessons of history. In no other profession do they attempt to determine standards prior to some degree of experimentation and experience.

    Java has suffered from this lack of experiementation. Java has also suffered from a slavish conservatism. New versions of Ruby not being backward compatible in the longer term may turn out to be a good thing.

    There does need to be a balance. The big issue facing Java today is allowing the JVM to properly support dynamic languages. I don't see this happening anytime soon. This will be Java's lost.EJB 3.0 is a positive response to developer lead, open source innovation, but will commercial implementations take off? I can't see why they would.
    BTW.

    A standard is a "standard" if it is generally accepted as such and is common property. Using this definition, open source implementations such as Hibernate qualify as a standard, incidently so does RoR.Interesting times ahead I think, and the outcome is by no means certain.

    Paul.

    I like dynamic languages and think there's a lot of value in them. From threads on TSS the last 6 months, Sun is responding to the community. Is the effort moving fast enough? For some, it is, while others it's not. Having features like anonymous types and methods will make it easier, but it's not necessary to write a dynamic scripting language for the JVM.

    In my freetime, I'm working on a RETE rule engine, which support LISP syntax. Would anonymous types and methods help? yeah, but it's not critical. Look at the plethora of scripting languages for the JVM.

    peter
  140. Open Source Java[ Go to top ]

    Is the effort moving fast enough? For some, it is, while others it's not. Having features like anonymous types and methods will make it easier, but it's not necessary to write a dynamic scripting language for the JVM.In my freetime, I'm working on a RETE rule engine, which support LISP syntax. Would anonymous types and methods help? yeah, but it's not critical. Look at the plethora of scripting languages for the JVM.peter
    Hi Peter,

    Imagine if Sun open sourced their JVM and Java implementation. We wouldn't need to wait for Sun for dynamic languages on the JVM. Special interest groups and academics could could create "experimental Java's" themselves, perhaps adding new capability like AOP, or even dynamic late-binding to the Java language itself. Over time the succesful experiments could be folded back into the core "standard" Java language.

    Who asked for Groovy for example? I didn't. I didn't ask fro Generics either.

    This is my point. All the blogs I've read by implementers of dynamic languages wishing to move their language onto a standard platform like the JVM or the CLR, say that they are hindered by lack of support. They wouldn't need support from Sun if Java was open source, they could just get on and do it themselves.

    Paul.
  141. Open Source Java[ Go to top ]

    They wouldn't need support from Sun if Java was open source, they could just get on and do it themselves.Paul.

    The result being a series of customised, non-standard and incompatible implementations.
  142. Open Source Java[ Go to top ]

    They wouldn't need support from Sun if Java was open source, they could just get on and do it themselves.Paul.
    The result being a series of customised, non-standard and incompatible implementations.
    Hi Steve,

    I was waiting for this response :^).

    So what is so wrong with that? I live in the UK and people speak several dialects. Have you ever tried to understand a scoucer? On formal occasions though everyone speaks standard English. Every now and then the odd cockney, brummy, etc. word makes it's way into "standard" English. It works, the English language has been evolving successfuly for hundres of years.
     
    What is the alternative? If we took the current Java approach the English language would have stagnated centuries ago and we would all still be talking "old English", or shoud I say "ye olde English".

    I just can't see any other way for software developement to successfuly evolve and change, without allowing for variants. We have variants at the moment. Some people write a fair amount of XML with their Java. I augment my Java with Ruby for testing. One cap doesn't fit all.

    My feeling is that premature standardisation kills innovation.

    Paul.
  143. You can already extend Java[ Go to top ]

    AFAIK, you can extend java all you want. You just can't call it java or claim to be compliant. For the record, I agree it would be great if Sun open sourced java, but that's not up to me to decide. There's already a few open source java implementations. They're not as mature or robust as Sun, JRockit or IBM jvm, but they are existing projects.

    peter
  144. You can already extend Java[ Go to top ]

    AFAIK, you can extend java all you want.
    OK, I didn't know this. Can you provide a reference?

    Paul.
  145. You can already extend Java[ Go to top ]

    AFAIK, you can extend java all you want.
    OK, I didn't know this. Can you provide a reference?
    Paul.

    http://www.kaffe.org/ - right on the homepage of kaffe, it states it explicitly they aren't licensed, but that it's legal to do a clean room implementation of Java. Anyone can fork kaffe and introduce extensions to the Java language. There aren't many people who have the skills, time and dedication to do though.

    considering there's already dozens of scripting languages that run on the JVM, the Java community is pretty active and innovating. Using Sun as an excuse isn't in my book. I get annoyed with various Sun stuff on a daily basis, but honestly I doubt I could do a better job guiding Java.

    peter
  146. another example[ Go to top ]

    AFAIK, you can extend java all you want.
    OK, I didn't know this. Can you provide a reference?

    Paul.

    Here is an example of people innovating and extending Java. http://www.cs.utah.edu/flux/janos/janosvm.html - Janos is doing interesting things.

    peter
  147. another example[ Go to top ]

    AFAIK, you can extend java all you want.
    OK, I didn't know this. Can you provide a reference?Paul.
    Here is an example of people innovating and extending Java. http://www.cs.utah.edu/flux/janos/janosvm.html - Janos is doing interesting things.peter
    Hi Peter,

    I think this bodes well. Not everyone will want to play with the internals of the JVM - but for researchers this is exactly the type of thing they should be doing. Once new ideas are proven then they become candidates for inclusion in the standard language.

    I remember reading the EJB 2.1 CMR spec. and thinking has anyone proven this stuff? Many of the new Java "features" are untried and untested. For example are we sure that Generics will actually help anyone?

    Paul.
  148. Isn't that the challenge?[ Go to top ]

    AFAIK, you can extend java all you want.

    OK, I didn't know this. Can you provide a reference?Paul.

    Here is an example of people innovating and extending Java. http://www.cs.utah.edu/flux/janos/janosvm.html - Janos is doing interesting things.peter

    Hi Peter,

    I think this bodes well. Not everyone will want to play with the internals of the JVM - but for researchers this is exactly the type of thing they should be doing. Once new ideas are proven then they become candidates for inclusion in the standard language.I remember reading the EJB 2.1 CMR spec. and thinking has anyone proven this stuff? Many of the new Java "features" are untried and untested. For example are we sure that Generics will actually help anyone?

    Paul.

    Deciding which features "should" get included is rather hard. Some people love generics, but I don't. That doesn't mean generics are bad, just that I wouldn't have included it. The inclusion of enumerations in jdk1.5 was a good thing in my mind. In my bias opinion, it should have been included in 1.3. Some people may disagree with me. Balancing the needs of a diverse group of people is very hard.

    I feel that Java is a healthy and has a diverse community. Much more so than .NET and Ruby. .NET tends to be used for certain apps, so it doesn't cover the same areas. Over time .NET will go after some of larger Java markets and Ruby may also do the same, but it's anyone's guess who well that will go. The fact that Java developers are actively talking about these issues tells me things are vibrant. Someone might see it differently

    peter
  149. Isn't that the challenge?[ Go to top ]

    I feel that Java is a healthy and has a diverse community. Much more so than .NET and Ruby. .NET tends to be used for certain apps, so it doesn't cover the same areas. Over time .NET will go after some of larger Java markets and Ruby may also do the same, but it's anyone's guess who well that will go. The fact that Java developers are actively talking about these issues tells me things are vibrant. Someone might see it differentlypeter
    I agree. The point for me is how do we innovate within Java. We have given serious thought to how we standardise, but IMO there doesn't seem to be a built in mechanism for innovation.

    Taking the example of Generics again. If there had been a research project using generics with Java, and it had published a paper and other had supported their work with collaborating result on how generics improved productivity or reduced bugs etc. The there would be a strong argument for inclusion.

    At the moment what gets included appears to be speculative. We think this will turn out to be a good thing so we add it to the standard. I just don't tink that is the way standards should work. People should be using something for a while and a body of opinion should exist that it is a good thing before it ends up in the standard. This is what I mean by proven.

    Paul.
  150. would better JCP transparency help?[ Go to top ]

    would modifying or opening the JCP process help fix that situation? I can think of several JSR's that didn't turn out the way I had hoped. One example is Java Content Repository. I spent a few days reading the spec and couldn't figure out exactly what the purpose was. I originally looked at the spec as a potential Rule repository, but after 2 days I gave up.

    Another example is JAXB. It started in 2K, stalled for a long time and then resumed in 2002-2003. One of the annoying things with JAXB is that I wished it used RelaxNG in the first release rather than XML Schema. The latest JAXB has some relaxNG support, but backing XML Schema was wrong in my bias opinion.

    so I agree there are cases where specs appear to be speculative or driven by execs. that's always going to happen with commercial products and efforts. Actively engaging the JCP is a good way to push it towards greater transparency.

    my 2 cents

    peter
  151. JCP is in stasis[ Go to top ]

    That's the real problem. Noone on the JCP is trying to fix it, as everyone seems to be very happy with the status quo. You can't fix problems while everyone is patting each other on the back, for two long years now. There is no JCP 2.8 in sight, afaict, so no fixes in the pipe in the next two years, either.

    Everyone knows that the JCP has massive problems with transparency: either you are part of the in-circle, or you are faced with the NDA crapola. That makes it very hard to figure out if a certain JSR is dead, vaporware, or just silently rotting away in like most JSRs that lend credibitly to dead code (Java3d, JMF, ...). JCP is full of dead wood, and JSRs going nowhere.

    Most of the output of the JCP fails to meet the requirements to be called an 'open standard'. It's more often than not just a way to give proprietary solutions the clout of an 'industry standard', In addition, the JCP, contrary to some other bodies that actually create open standards, will happily rubber stamp 'standards' that are encumbered with software patents.

    A lot of the output of the JCP is on par with the open source projects Hanni more or less eloquently biles about: it's late, it's bad, it's useless in practice. For example, JVM changes in the past 7 (in words: seven) years still have not led to an actual updated edition of the JVM specs ... great work there, JCP. I could hardly do it better myself if I was in charge of the JVM JSR.

    It's incomprehensible to me, how such a fundamental specification for Java, like the JVM spec, can be in such a rotten, out of date, state. Those that decry Ruby for not being professional, have presumably not have had the pleasure to try to puzzle together semantics of some core component of Java because the JCP is apparently incapable of publishing actual, updated specifications in seven years.

    cheers,
    dalibor topic
  152. JCP is in stasis[ Go to top ]

    Thanks for the insight. I've always felt that there is something very wrong with the JCP - just judging from its output.

    From what I see vendor lead "standards" committees, tend not to work very well. The OMG is another such like committee that hasn’t perform that well.

    I'm sure that someone will pipe up and say that the JCP is not vendor lead, in which case what excuse does it have for performing so badly?

    I'm guessing that improvements in the JCP would go along way to addressing the challenges facing Java today. I'm not an insider so I could be very wrong.

    Is there anyone out there who is an insider and has a view?

    I've also speculated that an "open source" model could help; anyone with a view?

    Lastly, standards should be based on working tried and tested implementations that have gained the support of the community, not on speculative "design by committee" paper specs IMO. This is occurring with EJB3.0 - does anyone know whether this is a trend that the JCP is encouraging? I know that this certainly isn't the approach being adopted with JSF.

    Paul.
  153. Open Source Java[ Go to top ]

    So what is so wrong with that? I live in the UK and people speak several dialects.
    You are forgetting one tiny detail: 99% of people who speak these dialects also speak English.
    the English language has been evolving successfuly for hundres of years.&nbsp;What is the alternative? If we took the current Java approach the English language would have stagnated centuries ago
    Sure, natural languages evolve, but very slowly.

    Just like Java.

    And it's a good thing.

    Now, don't get me wrong, I am certainly not saying that Java should not evolve (actually, I have been arguing for the opposite), but as opposed to you, I recognize the value of having evolved Java at a glacial pace so far.

    Still, at this point, I'd like Sun to work on a language that has a decent chance of being the "next big thing". Something that will rise to the software challenges we will be facing in the next ten years. C# 3.0 is a step in the right direction. I don't agree with all the features they are putting in there, but at least, they are doing something and trying to change the game and show some real, risky innovation.

    --
    Cedric
    TestNG
  154. Open Source Java[ Go to top ]

    So what is so wrong with that? I live in the UK and people speak several dialects.
    You are forgetting one tiny detail: 99% of people who speak these dialects also speak English.
    the English language has been evolving successfuly for hundres of years.&amp;nbsp;What is the alternative? If we took the current Java approach the English language would have stagnated centuries ago
    Sure, natural languages evolve, but very slowly.Just like Java.And it's a good thing.Now, don't get me wrong, I am certainly not saying that Java should not evolve (actually, I have been arguing for the opposite), but as opposed to you, I recognize the value of having evolved Java at a glacial pace so far.Still, at this point, I'd like Sun to work on a language that has a decent chance of being the "next big thing". Something that will rise to the software challenges we will be facing in the next ten years. C# 3.0 is a step in the right direction. I don't agree with all the features they are putting in there, but at least, they are doing something and trying to change the game and show some real, risky innovation.-- CedricTestNG
    I Agree. I'm making this point just to show the opposite side of the argument - which is often ignored.

    What is needed is balance. Peoples current investment needs to be protected, but this should not be at the expense of innovation. I think it is possible to achieve both.

    Paul.
  155. Open Source Java[ Go to top ]

    Still, at this point, I'd like Sun to work on a language that has a decent chance of being the "next big thing". Something that will rise to the software challenges we will be facing in the next ten years. C# 3.0 is a step in the right direction. I don't agree with all the features they are putting in there, but at least, they are doing something and trying to change the game and show some real, risky innovation.-- CedricTestNG

    Why Sun? You've got Josh Bloch and company over at Google... You guys should come up with the next big thing :-)
  156. Open Source Java[ Go to top ]

    C# 3.0 is a step in the right direction. I don't agree with all the features they are putting in there, but at least, they are doing something and trying to change the game and show some real, risky innovation.

    I've got the same feeling about Java lagging behind C# (and I've been using and advocating Java since version 1.0 - however I won't stop using it because I still like it). Those new C# 3.0 features are so cool for a mainstream statically typed programming language (e.g. type inference similar to the ML programming language family but with a nice syntax, linq - basically one single query syntax integrated in the language for dbs, xml, registry..., extension classes...) They give some of the biggest advantages of dynamic programming languages to a statically typed language without sacrificing type safety. Obviously Microsoft's decision to hire Anders Hejlsberg was perfect and Anders is doing a great job. And what great language feature did Gosling invent in the meantime? It's getting boring in javaland and the grass is starting to look greener on the other side and this is indeed a trend Sun should observe and do something against it.

    Regarding ROR: In my opinion the most likely scenario will be that bigger platforms will clone some of the better features of ROR and in the end there will be no reason to use ROR any more because ruby as a platform is to small, the programmers are too few and the productivity of the other platforms will match ROR's (good enough).

    If I was Bruce I wouldn't bet 100% on ROR just because of a perceived better productivity. I am almost sure that this kind of (perceived) bad java publicity from him will in the end hurt his java based income and I am not sure if his ROR income can make up this. But I could be wrong here...
  157. Open Source Java[ Go to top ]

    I recognize the value of having evolved Java at a glacial pace so far.Still, at this point, I'd like Sun to work on a language that has a decent chance of being the "next big thing".

    These two statements pretty much nail both sides of the argument. In Beyond Java, I argue that Java was successful precisely because Sun was a good steward of the language. Part of that was their conservative hand in enhancements.

    But the down side of that model is that you will eventually lag more aggressive innovation. I would like to see Sun push the JVM harder and adopt a broader suite of dynamic languages and modernized static languages (see Nice) on it. The JVM and the community are the real crown jewels. And they are not the focus of Java rigth now...not by a long shot.
  158. Is there hard proof of that statement?[ Go to top ]

    I recognize the value of having evolved Java at a glacial pace so far.Still, at this point, I'd like Sun to work on a language that has a decent chance of being the "next big thing".

    These two statements pretty much nail both sides of the argument. In Beyond Java, I argue that Java was successful precisely because Sun was a good steward of the language. Part of that was their conservative hand in enhancements. But the down side of that model is that you will eventually lag more aggressive innovation. I would like to see Sun push the JVM harder and adopt a broader suite of dynamic languages and modernized static languages (see Nice) on it. The JVM and the community are the real crown jewels. And they are not the focus of Java rigth now...not by a long shot.

    Not sure I understand that statement. Are you saying the community isn' focused on the JVM and Java? Or are you saying Sun isn't focused on the JVM and the java community. I don't see good evidence supporting that statement.

    From a community perspective, I see the java community building some innovative products on Apache, ObjectWeb and Codehaus. Contrary to the assertion that ROR is better than all other webUI frameworks, the wide variety of Java frameworks tells me the community is very diverse. If everyone (or majority) did things the same way, there would be fewer frameworks. others will disagree, but whether a framework is "better" is a subjective human factor and isn't a technological attribute.

    take CLIPS and LISP syntax for example. Many people love the java-ness of Drools, because many developers wouldn't touch LISP with a 100' pole. I prefer LISP syntax over java syntax for declarative rules, but clearly the majority disagrees.

    peter
  159. Open Source Java[ Go to top ]

    I recognize the value of having evolved Java at a glacial pace so far.Still, at this point, I'd like Sun to work on a language that has a decent chance of being the "next big thing".
    These two statements pretty much nail both sides of the argument. In Beyond Java, I argue that Java was successful precisely because Sun was a good steward of the language. Part of that was their conservative hand in enhancements.

    Bruce, why do you keep talking about Java's success in the past tense? You live in the past man!

     S.
  160. Open Source Java[ Go to top ]

    I recognize the value of having evolved Java at a glacial pace so far.Still, at this point, I'd like Sun to work on a language that has a decent chance of being the "next big thing".
    These two statements pretty much nail both sides of the argument. In Beyond Java, I argue that Java was successful precisely because Sun was a good steward of the language. Part of that was their conservative hand in enhancements.
    Bruce, why do you keep talking about Java's success in the past tense? You live in the past man!&nbsp;S.
    In that case, I was speaking about Java's success so far (and Sun's hand in it.) This has been the most successful language of all time. My point is that Sun and others had to make some necessary compromises to make it so.
  161. Beyond the JVM[ Go to top ]

    Sun can't push the JVM harder, since the JVM is by design suitable for a certain set of problems: distributed, small proprietary applications on a network. Coincidentally, that's the one area in which Sun makes some really good money from licensing Java: mobile application runtimes.

    As long as Sun makes money off being a proprietary software vendor, you are not going to see open source J2SE from Sun, because they'd be handing the mobile runtime market to others (i.e. Microsoft) on a silver platter, and killing off their Java licensing revenue stream. Not such a good idea for a company struggling to break even.

    Given the steadily increasing capabilities of mobile devices, you can expect that Sun will try to keep their maintainance costs down by merging J2ME and J2SE at some point in the future, since J2ME is pointless for devices that are as capable as PCs just a few years ago.

    So forget open source Java, J2SE will stay proprietary for a long time to come. You may be able to get J2SE compatible versions of Kaffe, Apache Harmony or gcj at some point in the future, but Sun will make sure that those independent implementations stay behind in the same way they've done so far: by not releasing the full specs for the updated JVM versions for years.

    Mind you, the JVM is not really a good platform for much beside Java. The JVM language is (obviously, by design) very, very Java-oriented, and pretty horrible as a generic IR for arbitrary programming languages. There is a reason why, despite almost 10 years of alternative language implementations for the JVM, none of those JVM-based implementations has managed to reach the popularity of the C-based implementations, despite the total awesomeness of the JVM apparently assumed by Java developers.

    The JVM is unlikely to change radically in the future. One could see with generics, which also took almost 10 years going from Pizza, over to GJ, to finally morph into something that sort of works on top of the original JVM design, without breaking code all over the place, and screwing badly with the type system & the verifier. The JVM language has been remarkably static in the past 10 years, despite many, many calls to change this or that. The problem is that changing the original design in ways that don't involve breaking binary compatibility is very, very hard.

    Any new radical change to the JVM would have to mess with the type system, the security model and the verifier, and that in turn would gain Sun a big fat nothing in the market in which they already sell their proprietary software licenses quite successfully: the mobile runtime market. Java finally is starting to work well for Sun, so there is no reason for them to change anything. Your mileage may vary, but the JVM is certainly not going to see major changes as long as it is bringing in good money with its original design.

    As for community being a crown jewel, I have my doubts, having been part of that community since the early days.

    To a not so small extent, the Java community is made up of 'enthusiasts' and 'gratis==free, right tool for job' sort of developers. The 'enthusiasts' are apparently moving on, according to Bruce Eckel, or busy flaming those that are moving on. The 'right tool for the job' developers will move on to .NET sooner or later, since there is no need for two proprietary managed runtime frameworks on Microsoft Windows Vista: Whidbey will be the new standard, on each shipped PC, starting late this year. It's hard to compete against that, as Sun found out with applets, and Netscape found out with their proprietary Navigator browser. Ubiquity + gratis tools, like Visual Studio Express, and many Java developers will start finding that there are better, equally proprietary, but still wondefully gratis, tools for their jobs, just like how applets were replaced by Flash. And if those migrating developers really deeply care about WORA (and most Java developers really don't, or I wouldn't see so much broken code out there using unspecified sun.* and com.sun.* classes directly), there is still Mono, Rotor, or whatever intriguing illusion of silver bullet portability a market exists for.

    That doesn't mean that Java or the JVM are dead: they are alive and kicking in their niches, and it turns out that the niche is pretty large at the moment. But just like CORBA or C, for a lot of things the JVM is not the ideal solution, and won't ever be. For many of its niches, better ways to do things will turn up, and that's great. and can't be changed. The world would be a sad place if we were all stuck writing C just because it used to be the best tool for a lot of jobs a while ago.

    I don't think that many Java developers will migrate to Ruby, though. I'd expect most of them to migrate to C#, which offers a familiar setup, from the similar language constructs, and a VM, to the big, caring, proprietary software vendor talking sweet talk about'community' and 'enterprise'.

    See, if your theory about the superiority of the JVM and the Java community was correct, we would have seen people migrating in droves to JRuby from ruby, to Jython from python, etc. That's not what's been happening.

    You may want to check out Virginia Postrel's 'The future and its enemies', a nice book that should give you some understanding of the social interaction going on in the Java community atm for your next book. Beats sporting koans, in my opinion. :)

    cheers,
    dalibor topic
  162. Beyond the JVM[ Go to top ]

    As for community being a crown jewel, I have my doubts, having been part of that community since the early days. To a not so small extent, the Java community is made up of 'enthusiasts' and 'gratis==free, right tool for job' sort of developers. The 'enthusiasts' are apparently moving on, according to Bruce Eckel, or busy flaming those that are moving on. The 'right tool for the job' developers will move on to .NET sooner or later, since there is no need for two proprietary managed runtime frameworks on Microsoft Windows Vista: Whidbey will be the new standard, on each shipped PC, starting late this year.
    It's hard to compete against that, as Sun found out with applets, and Netscape found out with their proprietary Navigator browser. Ubiquity + gratis tools, like Visual Studio Express, and many Java developers will start finding that there are better, equally proprietary, but still wondefully gratis, tools for their jobs, just like how applets were replaced by Flash.

    And I thought the "you'll be absorbed, resisting is futile" kind of argument was gone long ago. That makes open source bigots look very rational and understanding people. :)

    Reading this long thread I get amazed how people can write a bunch of things just by taking assumptions for granted, not questioning and trying to reach a conclusion based on observable facts but instead putting here a "wish list" of things he/she would like to be.

    Is the Java community a place for sophists to exercise their ability to persuade?

    A tip on how your arguments fall apart:

    - You overgeneralized the "Java community" and used two unproven symbols (enthusiasts moving on and what "do the job" developers want) to base you line of thinking;

    - You didn't clarify what an enthusiast and "do the job" developers are. And for better limitation of scope you'd also need to clarify the other types of developers inside and outside Java community.

    - You didn't list the tools options from both sides for a comparison of features, "wonderfully gratis Visual Studio" doesn't say much about things, only about your personal opinion;

    - Your "JVM is bad" argument is solely based on the fact that there aren't open source zealots migrating in masses to it (sic). Maybe if there were a "GNU" in front of it, GNU/JVM, and there were 87 different and incompatible versions of it available, they would come. :)

    Please rectify your logic and resubmit your thought in a way of adding useful knowledge to all of us.
  163. Beyond the JVM[ Go to top ]

    You misunderstood me, unfortunately.

    I am not saying that we'll be absorbed. Not at all. Java is meets the feel-good spot for a lot of people coming from a certain procedural-OO-light background, and it's been designed that way. Read Gosling's white paper for the details.

    A lot of people are happy writing C/C++ code today, and have no need for Java, even though Java is a to a certain extent a nicer language in comparison, in my opinion. The JVM you're (most likely) using to run your applications is written in C, for example.

    That doesn't mean that you can't write a JVM in Java. You can, and as Sun has found out in their research implementation, you'll have abysimal performance. Unless, like JikesRVM guys, you extend the Java language and the JVM with specific constructs to allow you to mess with memory more directly (and deal with synchronization, in particular). But integrating such changes into the original JVM design without breaking code, security and all that, is a very hard problem. Maintenance is a harsh mistress.

    Similarly, a lot of people are happy with Java as it is, and have no use for ruby, python, o'caml, you name it, because what they have does the job, it solves the problems they need solving in a way they are comfortable with.

    There are some problems, which can be solved particularly well with Java, since its been designed to solve them, in the first place. Small proprietary apps on mobile devices, for example. You need a verifier, network-aware application loading, etc. The JVM design to a certain degree naturally falls out from the problems Sun tried to solve with it.

    Then there are some problems, for which Java currently offers a comparatively good solution for the job, but hasn't been designed to solve. There opportunities exist for better solutions, designed to solve the problems, to take over those niches. For example, you can write neat GUI applications for Windows today using Java5 and/or SWT. Once Vista ships with bundled Whidbey, though, GUI application developers on Windows will be facing an interesting choice: n MB for a C# application on Whidbey, or n MB + sizeof(Sun JRE 1.6) for a Java application. As we've seen with applets vs flash, there is a very simple answer: the ubiquitous one wins. See Netscape vs IE, which was decided the moment Microsoft bundled the browser with the OS.

    And just like we've seen with HTML & applets, the dominant, bundled platform is the one where the majority of the money ends up being on. Pragmatic developers will follow the money, since they need to make money to put food on the table. Your characterisation of open source 'bigots' and 'zealots' reinforces what I am saying: There are very few 'bigots' and 'zealots' in the Java community, but there is a lot of pragmatic people who care about their bottom line. If better ways turn up to make them money, they will move on to those, and who knows, maybe even write books about it. The same things happened in the C/C++ communities after a few years when Java started turning into a nice solution for specific problems that were dominated by C/C++ before.

    See, even if by some magic act Sun, contrary to their obvious business interests, decide to open up the source code of their VM, it would still change nothing: the JVM is, by design, only really suitable for Java-like languages. Anything beside that requires major changes to the existing design, that could wreak havoc on type-safety, etc. That's why those changes have not been made, in the first place. Sun's JVM developers are definitely not dumb, they aren't newbies to the field, and they have certainly heard of functional languages before, Steele has written the book on Lisp, after all. But the existing design can't really be extended very easily without potentially breaking 10 years of existing code, so ... the wiggling area is not that large.

    Beside, there is the small problem that Sun has when it comes to opening their J2SE code: Sun has noone in the J2SE team that comes close to being a person who a) understands open source development, b) understands J2SE in detail and c) can work with the existing JVM community to integrate the various developments. There is no Linus, who could rally JVM developers on building that better, shinier Ueber-JVM everyone seems to hope for. There are a lot of nice people at Sun who meet either a, b, or c, but I've yet to see anyone at Sun who could actually pull off successfully managing an open sourced J2SE project, and not turning it into another Sun-vs-Open-Source-Developers PR desaster.

    cheers,
    dalibor topic
  164. Beyond the JVM[ Go to top ]

    Dalibor Topic, you have an interesting analysis of various things. But you remind me of a guy that used to (and I presume still does) post on another software site and would claim that if everybody would just embrace KDE/Qt then the linux desktop would magically come to the mainstream. Well, Novell bought Suse and Ximian and shifted focus onto Gnome development and lo-an-behold his tune changed very fast. When the realization came that Novell joined RedHat and Sun as a Gnome shop, there was no more point in being A#1 KDE fanboy and he allowed himself to look at the situation realistically.

    Now I know you're part of the open source JVM, class libraries crowd, and as you just said, you don't think Sun will ever "open source" Java. So has this apparent reality of Sun never "open sourceing" Java somehow changed your view of Java on the client and as a platform for other languages? Call me cynical, but that's what it seems like.

    "Since Sun isn't going to open source Java, I might as well just tell it like it is instead of being a cheerleader".

    In any case, I agree with you as far as the rich client is concerned. Sun had their chance to put something together great for the desktop and never did. .NET will be ubiquitous soon enough. But Java still has a good position in the mobile device space, even though Microsoft is already taking the high-end mobile devices.
  165. Beyond the JVM[ Go to top ]

    So has this apparent reality of Sun never "open sourceing" Java somehow changed your view of Java on the client and as a platform for other languages? Call me cynical, but that's what it seems like.

    Not really, no. Write a Java compiler, hack on your own JVM for a while, like I did, and you'll notice the strengths and weaknesses of the JVM design.

    Same goes for CLR, it also doesn't solve many problems that well, but it addresses some problems that the JVM wasn't really designed to deal with, like integrating somehow effectively with native code. CLR is ahead of the JVM, there, but then, Microsoft cared a lot about leveraging the existing native code.

    Sun didn't design the JVM with that in mind, so Sun's strategy was to persuade people to rewrite their code in 'pure' Java. Which worked quite well for Sun, and shows that people will part ways with their legacy code, if a) they have to and b) the environment they are migrating to provides a substantial productivity gain, like Java did wrt C/C++. Sun's Guy Steele has very clever things to say on migrating developers to greener pastures, in the context of Fortress vs. Fortran and Java vs. C++.

    I have yet to meet a Sun employee who would make a business case for an open source J2SE, and I've had the pleasure to talk with quite a couple of very bright people working for Sun in the past years. You only need to look at the lack of thriving multi-million open source J2SE companies to see that there is no business capable of keeping a company of the size of Sun afloat in that direction, so that's not where they are going to go. If giving up J2SE is not going to make Sun more money than they make now, as a proprietary software vendor, it's not going to happen. It's not like the current model has been working that bad for Sun, after all.

    Otoh, mobile runtime environments are finally making it possible to actually monetize some of their investment in Java, since those environments play right into the hands of what the JVM is good at. It would be unrealistic to expect Sun to let go of J2SE, when they can finally make some real money off it, after being so badly ridiculed for letting IBM, BEA and others secure the larger chunk of the Java enterprise cash.

    On a side note, Linux on the Desktop? The day that Firefox wins the browser war against Internet Explorer and Duke Nukem Forever is released. ;)

    cheers,
    dalibor topic
  166. Beyond the JVM[ Go to top ]

    Thanks for the response Dalibor. I guess my 9 years of using and programming Linux at work and then listening to open source group-think stupidity has made me a cynic:)

    I agree with your analysis regarding J2ME. It's the only thing that Sun can make money off of Java with and if they can't risk allowing another implementation to gain a foothold.
  167. Beyond the JVM[ Go to top ]

    Sure, no worries. Being a cynic helps to keep the signal-to-noise ratio at a good level. ;)

    For how yucky it is to have to deal with backwards compatibility, see Neal's wonderful little blog entry[1] explaining the backwards (and migration) compatibility constraints and their influence on the design choices they made for generics.

    Really good reading for Java developers assuming that the JCP can simply quickly introduce a new bytecode or two into the JVM design to implement their favourite feature efficiently.

    cheers,
    dalibor topic

    [1] http://gafter.blogspot.com/2004/09/puzzling-through-erasure-answer.html
  168. non-java languages with JVM[ Go to top ]

    I am pretty sure that it would be possible to run non-java languages similar to java (like C# or like some preprocessor extensions allowing operator overloading in Java) in the JVM efficiently.

    I am not sure, but I tend to believe the statement that the JVM is not optimal for dynamic languages. The guys doing Perl 6 had to make that decision and they chose to write their own VM (parrot) instead of going for the one of Java or c#/dotnet, at least in the first step.

    Also we have to see that JRuby is even one step worse, because it actually reimplements the whole Ruby system in Java, so the Ruby-interpreter is running on top of the JVM and Ruby is not compiled into JVM-bytecode. Or am I wrong on this?

    I think that there will be some use for running stuff in the JVM, but the advantage of a VM like parrot seems to be so big that I don't expect that it will be disregarded. Btw. Perl, Python and Ruby all have the platform independence that Java offers as well.

    For interoperation between Perl/Python/Ruby/Tcl/.. and C/C++/Java we need to have strong and easy to use tools. This need not be by running everything in the JVM, although that would make things simple. Corba would be an option, but it is kind of too expensive for non-gigantic projects.
    Maybe Soap. Maybe even as low-level as RPC. But I would also consider XML-RPC (which is quite different from RPC!) as very promising.

    If C is used as system programming language, components written in C are relatively easy to integrate into Ruby. But I get the feeling that this approach already breaks when combining Java or C++ with Ruby. And using C where Java or at least C++ would do the job is really not very good. So something like XML-RPC seems to be a good way to go.
  169. non-java languages with JVM[ Go to top ]

    I am pretty sure that it would be possible to run non-java languages similar to java (like C# or like some preprocessor extensions allowing operator overloading in Java) in the JVM efficiently.

    C# is a bit special, since it is a richer environment than the Java, so you need to do a bit of work to make the parts that don't exist in the JVM work transparently. For details, see Staerk's papers on semantics of Java/JVM and C#/CLR.
    I think that there will be some use for running stuff in the JVM, but the advantage of a VM like parrot seems to be so big that I don't expect that it will be disregarded. Btw. Perl, Python and Ruby all have the platform independence that Java offers as well.For interoperation between Perl/Python/Ruby/Tcl/.. and C/C++/Java we need to have strong and easy to use tools. This need not be by running everything in the JVM, although that would make things simple.

    The JVM makes everything beside Java a second-class language. There is little point for other language implementors to tie themselves to a platform that noone beside Sun effectively controls. Sun has no business interest in pushing alternative languages for the JVM it can't control, since it's not selling anything for those particular languages, and they are actively competing with something Sun wants to sell, i.e. proprietary JVMs.

    Phone companies wouldn't be buying Sun's proprietary JVM sources to run JRuby, they'd just take the real Ruby and port it to their phones to run a few orders of magnitude faster than JRuby, without paying a dime to Sun. There is no way Sun would assist people migrating away from platforms they exclusively control to someting that's actually allowing vendors to do whatever they want without paying royalties to Sun. Letting people do whatever they want won't be making Sun any money, so that's not going to happen, ever, and that in turn makes the JVM very unattractive for high performance implementations of anything else but whatever language Sun is selling commercial support for.
    If C is used as system programming language, components written in C are relatively easy to integrate into Ruby. But I get the feeling that this approach already breaks when combining Java or C++ with Ruby. And using C where Java or at least C++ would do the job is really not very good. So something like XML-RPC seems to be a good way to go.

    SWIG + gcj may turn out to be a good choice for integrating 'legacy' Java bytecode with dynamic languages in the future. That's what the Chandler guys are doing with Python + Lucene with some pretty good success. IKVM is doing something similar for people using libraries written in the Java programming language with .NET. There may be a nice little revenue stream in a transparent bridge for Java 'legacy' code for PHP and Ruby users.

    Don't expect any help from Sun, there, though, as that's not in their business interest, as a proprietary software vendor.

    cheers,
    dalibor topic
  170. LISP is coming[ Go to top ]

    Hello Peter
    We decided to go with Lisp for rule engines in our company.
    In fact we would go for all other stuff with lisp too, if not the lack of certain libraries.

    I think the emergence of dynamic "bastard" languages that bring more and more "lispish" stuff into the mainstrim (like Ruby, or Python) is a very good indication that time of LISP has come.

    Lisp is light years ahead of anything that is available now, or will come in the future.
    Things like GC, OOP, functional programming, lambda, aspects, you name it,
    were available in lisp decades before they appeared in any mainstream and popular language.

    And the best things is - LISP does not need committie do decide what should be in langauge. All that stuf is designed as libraries and is not in core of the language.
    So developers do not have to wait years for new version of language.
    But at the same time, they do not look like libraries of funciotns. They are actualy part of language itself (DSL)

    Talk about DSL. This is such a cool buzzword nowadays.
    RoR is DSL as they say.
    Everybody thinks that DSL is the way to go in terms of development of programming languages.

    But the things is - languages with such rigid, stiff and cumbersome synthax like java, or scharp are not good at creating DLSs at all.

    While lisp is all about creating DSLs

    I think you guys do not see that these small dynamic languages are the sign that somehting much bigger and powerfull finally is coming to take its rightfull place as THE ONLY LANGUAGE.
    LISP IS COMING !
    :)))
  171. Java has suffered from this lack of experiementation. Java has also suffered from a slavish conservatism.

    I really don't think that is true. Java is quite deliberately slow-moving in adopting ideas because that is what is absolutely necessary for it to be the foundation for long-term commercial use. It is a sensible approach, but not slavish.
    New versions of Ruby not being backward compatible in the longer term may turn out to be a good thing.There does need to be a balance. The big issue facing Java today is allowing the JVM to properly support dynamic languages. I don't see this happening anytime soon.

    If it was a big issue, Java would not be where it was today. I think it will become increasingly important, and there are signs that this will happen: I would expect a new bytecode or two to help with this in the successor to Mustang.
    This will be Java's lost.EJB 3.0 is a positive response to developer lead, open source innovation, but will commercial implementations take off? I can't see why they would.

    Commercial engines that will implement EJB 3.0 are already successful.
    BTW. A standard is a "standard" if it is generally accepted as such and is common property. Using this definition, open source implementations such as Hibernate qualify as a standard, incidently so does RoR.

    No, they really don't. Sorry, but I have to disagree with you there. Standards have to have things like commonly agreed references.
    Interesting times ahead I think, and the outcome is by no means certain.Paul.

    Sorry, but I think it is. Java will be around for a long time, just as C and C++ have been. The 10-year cycle argument is a fallacy: C still dominates in many areas and it has been around for over 30 years. No-one could say that C++ is near death and it is over 20. IT does not progress by dramatic changes or revolutions. Even the apparent "meteoric" rise of Java (as someone said recently on another thread) has taken over a decade.

    There will be interesting times, as new ways to be productive with Java and the JVM appear, including through the use of dynamic languages in combination with those technologies. But, in terms of the lifespan of Java as a mass-use development language, it is very early days.
  172. Commercial engines that will implement EJB 3.0 are already successful

    I guess it depends on how you define success. What you mean is that a lot of people have been convinced to part with good money. As is common knowledge, lighter solutions that avoid these engines and use open source technology are often a much better (and cheaper) way to go.

    I guess this is the Crux. You can't serve two masters. The "Java Community" cannot claim to represent the interests of developers/customers and the interests of the vendors all the time. At some point these two interests will be in conflict.

    Incidently as I understand it, EJB3.0 prescribes that your container must support EJB2.1 aswell. Why? If I have no interest in EJB2.1 why would I buy a EJB3.0 App. Server when I can download Spring and Hibernate for free?

    This story still needs to play itself out. It will be interesting watching what happens.
    But, in terms of the lifespan of Java as a mass-use development language, it is very early days.
    I agree with you. I interpreted the title "Dead like Cobol not like Elvis" to mean that Java will no longer be the leading vehicle for new ideas and innovation in the software industry. Languages live on as long as legacy systems do, but legacy is not innovation. The question is whether Java is entering it's "legacy" phase? To me the answer to this question is still open.

    Paul.
  173. Commercial engines that will implement EJB 3.0 are already successful
    I guess it depends on how you define success. What you mean is that a lot of people have been convinced to part with good money. As is common knowledge, lighter solutions that avoid these engines and use open source technology are often a much better (and cheaper) way to go.

    And often, they are not. Personally, I don't trust anything labelled 'common knowledge' :)
    I guess this is the Crux. You can't serve two masters. The "Java Community" cannot claim to represent the interests of developers/customers and the interests of the vendors all the time.

    Why not? After all, vendors sell to customers.
    At some point these two interests will be in conflict.

    Again, too simple an analysis.
    Incidently as I understand it, EJB3.0 prescribes that your container must support EJB2.1 as well

    Not if you just want to implement the new POJO persistence architecture.
    why would I buy a EJB3.0 App. Server when I can download Spring and Hibernate for free?

    It depends what you need these for. I have no benchmarks for Hibernate in my use cases, but I use JDO persistence engines for applications which perform single transactions which involve hundreds of thousands of objects. They work well and give high performance. I assume that the EJB 3.0/JPA implementations on these engines would work equally well. I want a situation where if performance isn't adequate, I can take my business to an alternative vendor. Standards are important to me.
    This story still needs to play itself out. It will be interesting watching what happens.
    But, in terms of the lifespan of Java as a mass-use development language, it is very early days.
    I agree with you. I interpreted the title "Dead like Cobol not like Elvis" to mean that Java will no longer be the leading vehicle for new ideas and innovation in the software industry. Languages live on as long as legacy systems do, but legacy is not innovation. The question is whether Java is entering it's "legacy" phase? To me the answer to this question is still open.Paul.
    Seeing as new features in recent releases of Java still probably haven't reached mass adoption, I think the answer is clear.
  174. Commercial engines that will implement EJB 3.0 are already successful
    I guess it depends on how you define success. What you mean is that a lot of people have been convinced to part with good money. As is common knowledge, lighter solutions that avoid these engines and use open source technology are often a much better (and cheaper) way to go.
    And often, they are not. Personally, I don't trust anything labelled 'common knowledge' :)
    Fair enough, but I don't think Rod Johnson and many other would agree. My last two J2EE projects haven't used EJB's or App Servers. My current technology stack is Tomcat, Spring and Hibernate. I think this is a common trend.
    I guess this is the Crux. You can't serve two masters. The "Java Community" cannot claim to represent the interests of developers/customers and the interests of the vendors all the time.
    Why not? After all, vendors sell to customers.
    I'd thought this would be obvious. If car manufacturers owned the roads, do you think they would "manage" them for the benefit of the motorist or for the benefit of their shareholders?
    why would I buy a EJB3.0 App. Server when I can download Spring and Hibernate for free?
    It depends what you need these for. I have no benchmarks for Hibernate in my use cases, but I use JDO persistence engines for applications which perform single transactions which involve hundreds of thousands of objects. They work well and give high performance. I assume that the EJB 3.0/JPA implementations on these engines would work equally well. I want a situation where if performance isn't adequate, I can take my business to an alternative vendor?. Standards are important to me. ?
    So Steve, when was the last time you took your business to another vendor? In practice this rarely if ever happens - there are lots of reasons why.
     
    I agree with you. I interpreted the title "Dead like Cobol not like Elvis" to mean that Java will no longer be the leading vehicle for new ideas and innovation in the software industry. Languages live on as long as legacy systems do, but legacy is not innovation. The question is whether Java is entering it's "legacy" phase? To me the answer to this question is still open.Paul.
    Seeing as new features in recent releases of Java still probably haven't reached mass adoption, I think the answer is clear.

    I see "features" as being very different to innovation. I've got a DVD player with loads of features, I never use most of them though :^).

    I see where your comming from and I use to think the same way when it comes to standards, but I know question a lot of the assumptions you make. I just don't think they fit real world experience.

    Paul.
  175. My current technology stack is Tomcat, Spring and Hibernate. I think this is a common trend.

    Sure it is a common trend, but it is also common for large commercial projects to use other products. You can't generalise.
    I'd thought this would be obvious. If car manufacturers owned the roads, do you think they would "manage" them for the benefit of the motorist or for the benefit of their shareholders?

    Why do you assume that they can't do both at the same time? Much of the time the interests of the two co-incide.
    So Steve, when was the last time you took your business to another vendor? In practice this rarely if ever happens - there are lots of reasons why.

    Sorry, but in practice, it really does happen. I recently moved my JDO work to a different commercial vendor for various reasons (support and performance).
    Seeing as new features in recent releases of Java still probably haven't reached mass adoption, I think the answer is clear.
    I see "features" as being very different to innovation. I've got a DVD player with loads of features, I never use most of them though :^).I see where your comming from and I use to think the same way when it comes to standards, but I know question a lot of the assumptions you make. I just don't think they fit real world experience.Paul.

    My assumptions are from actual real world experience. I have dealt with so-called 'de-facto' standards. I have dealt with serious issues from lack of backwards compatibility. I have seen the slow adoption of Java in real situations, indicating it has a fair way to go yet before it peaks in terms of adoption. I have made use of the flexibility standards have given my by switching vendors when support has been inadequate.
  176. My assumptions are from actual real world experience. I have dealt with so-called 'de-facto' standards. I have dealt with serious issues from lack of backwards compatibility. I have seen the slow adoption of Java in real situations, indicating it has a fair way to go yet before it peaks in terms of adoption. I have made use of the flexibility standards have given my by switching vendors when support has been inadequate.
    It looks as though our experiences have been quite different. Clearly Java as it is today is working well for a lot of people. I also think that many others have had experiences similiar to myself - and have found that Java isn't delivering, and are searching for alternatives. Many of the most promising alternatives to Java are open source.

    There are pros and cons with open source as compared to vendor solutions. I guess you pays your money and you take your choice.

    Paul.
  177. There are pros and cons with open source as compared to vendor solutions. I guess you pays your money and you take your choice.Paul.

    This is where I think generalisations are really wrong. I really don't think that the issue is open source vs. vendor solutions. I think this is a mistaken and somewhat arbitrary division; I think you are implying that open source tends to be more tailored to the end user and more innovative. Well, some open source products are, and some aren't.

    I don't think you can even say 'there are pros and cons with open source....' unless you specify the open source project you are talking about!
  178. I don't think you can even say 'there are pros and cons with open source....' unless you specify the open source project you are talking about!
    Hi Steve,

    I think you are reading into my words meanings that aren't there. A pro that you can say about all open source is that you can always tweak the implementation because you have the source. There are also general cons, like there is no guaranteed support.

    Open source is having a big impact on software at the moment and it has the power to change some of our long held assumptions. The contrast with vendor software is meaningful IMO.

    Paul.
  179. I don't think you can even say 'there are pros and cons with open source....' unless you specify the open source project you are talking about!
    Hi Steve,I think you are reading into my words meanings that aren't there. A pro that you can say about all open source is that you can always tweak the implementation because you have the source. There are also general cons, like there is no guaranteed support.Open source is having a big impact on software at the moment and it has the power to change some of our long held assumptions. The contrast with vendor software is meaningful IMO.Paul.

    Can we all stop using the argument "You have the source and you can modify or do anything with it" as a huge benefit to Open Source. It's irrelevant in 99% of the cases. If a developer wants to join a OS project for his/her entertainment/hobby, they can do so, but to a corporation, that is not a benefit. Let's see, I remember working for Ford years ago and a few Linux companies approached us trying to get us to switch to Linux for app and database deployment platform. The first argument was "you can modify the source". Most companies are not in the business of modifying and supporting libraries/software. They would rather buy it, get it, and pay someone to support it. Non-IT companies, build business software, and are not in the business of retaining kernel developers on their staff. This argument goes to the rest of OS software as well.

    OS software benefits are huge, but not the one mentioned above.

    Ilya Sterin
  180. Open source is having a big impact on software at the moment and it has the power to change some of our long held assumptions. The contrast with vendor software is meaningful IMO.Paul.

    And I really don't think it is. It changes some of our long held assumptions about how software is distributed and marketed, but I don't think that it is a factor one way or the other in terms of changing assumptions and innovation. For example, there have been many innovative and pioneering languages over the decades: examples are Fortran, LISP, Algol, C, Pascal, Smalltalk, Prolog, C++, Java. Has open source-ness been relevant to the innovations present in any of the languages mentioned above? No, not that I can see; the concept wasn't even around when most of these languages were devised.
  181. "Improvement" versus "Paradigm Shift"[ Go to top ]

    Open source is having a big impact on software at the moment and it has the power to change some of our long held assumptions. The contrast with vendor software is meaningful IMO.Paul.
    And I really don't think it is. It changes some of our long held assumptions about how software is distributed and marketed, but I don't think that it is a factor one way or the other in terms of changing assumptions and innovation

    You may be right, but I'm not so sure. I have been spending a lot of time lately working with Squeak. The Squeak community have a very differently philosophy to change and then us Java folk. In this explanation by Dan Ingalls acknowledges two often conflicting planes of future improvement:
    There are two strong, often opposed forces at work in the Squeak team. But, we have managed to keep it together long enough that it's probably adequate to articulate the two and you can guess at where equilibrium will take us. These were most recently articulated in Alan's allusion to Koestler's metaphor of progress in two orthogonal planes: a horizontal pink plane of incremental improvement, and a vertical blue plane of paradigm shift. The colors are Alan's.
    Here is the full article:
    http://minnow.cc.gatech.edu/squeak/158

    Using this definition, innovation tends to occur in the blue plane. The "Squeak community process" actively manages both. A look at the list of the current squeak projects reveals this:

    http://www.squeak.org/Projects/

    In the "blue plane" are Croquet and Seaside, projects that I consider to be amongst the most innovative in software development today.

    I do not see the language barrier as real. We are all software developers, and I'm sure we could adopt the same ideas in Java. My feeling is that the Java community has got the pink plane covered - but perhaps we could learn a few things in the blue plane :^)

    I'm posing the question, that if the centre of gravity in the Java community shifted towards an open source model, would that result in a change in philosophy? Squeak is open source - and their freedom to attend to "blue" issues may be as a consequence of this. I really do not know. I'm just posing the question.

    Paul.

    BTW here is the quote of the day from the squeak wiki. I think it's quite apt:
    Certainty is often an illusion, and repose is not the destiny of Man. – Aristotle
  182. "Improvement" versus "Paradigm Shift"[ Go to top ]

    Squeak is open source - and their freedom to attend to "blue" issues may be as a consequence of this.

    And I am pretty sure it isn't - Smalltalk has been shifting paradigms for years - decades even - without having an open source implementation.

    Talking about paradigm shift - one of the most dramatic I can think of computing recently is the use of garbage collection and VM-based languages for mainstream general-purpose use. The language that has led this shift is Java.
  183. "Improvement" versus "Paradigm Shift"[ Go to top ]

    Talking about paradigm shift - one of the most dramatic I can think of computing recently is the use of garbage collection and VM-based languages for mainstream general-purpose use. The language that has led this shift is Java.
    Wow, A bit defensive! Like I said before I don't think this is about language A versus language B. We are all software developers facing similar challenges what ever language we use.

    Java built on ideas that existed before it. All languages borrow from each other. Surely if there is something to learn from other programming communities then the Java community can only gain?

    Part of the problem with this debate is that a lot of people seem to build their identity on what they do. I do not identity myself as a Java developer or a Smalltalk developer. I'm me, programming is just something I do. I try not to forget this.

    Peace.

    Paul.
  184. "Improvement" versus "Paradigm Shift"[ Go to top ]

    Talking about paradigm shift - one of the most dramatic I can think of computing recently is the use of garbage collection and VM-based languages for mainstream general-purpose use. The language that has led this shift is Java.
    Wow, A bit defensive! Like I said before I don't think this is about language A versus language B. We are all software developers facing similar challenges what ever language we use.Java built on ideas that existed before it. All languages borrow from each other. Surely if there is something to learn from other programming communities then the Java community can only gain?Part of the problem with this debate is that a lot of people seem to build their identity on what they do. I do not identity myself as a Java developer or a Smalltalk developer. I'm me, programming is just something I do. I try not to forget this.Peace.Paul.

    I wasn't trying to be defensive, or pitching one language against another. I was simply pointing out that one of the most significant paradigm shifts in IT was led by a language that was not open source. Sure, Java did not pioneer these ideas, but it evidently made them practical. I like the idea of open source, and I like the idea of a variety of languages. However, I think it is far too simplistic to equate open source with innovation and to contrast this with closed source in this way. The long history of IT provides ample evidence to the contrary.

    That is all I am saying.
  185. "Improvement" versus "Paradigm Shift"[ Go to top ]

    That is all I am saying.
    I hear you.

    P.
  186. Recurrent patterns[ Go to top ]

    Part of the problem with this debate is that a lot of people seem to build their identity on what they do. I do not identity myself as a Java developer or a Smalltalk developer. I'm me, programming is just something I do. I try not to forget this.

    Not following your discussion with the other guy, but just noting a few things, not related exactly to what you're saying but interesting to make a point.

    I believe part of the problem is the inability of some to come with really good points on why Java is doomed. They base their whole argumentation on failed assumptions.

    Please note the recurrent patterns from Ruby zealots:

    - Java has nowhere to go from here: wrong assumption;

    - Java is web applications, so if Ruby takes over web applications (CRUD) Java is dead: wrong assertion;

    - This cool language feature is ALL we need: not true, a good platform is all developers need;

    - If you don't accept my words that means you're dumb (or have identity crisis as you said): this "superiority" rant I often find in Ruby zealots, who curiously didn't know what functional languages were before Brute Tate's book;

    - Open your mind: that means "Don't question, accept it blindly" :);

    - Everything changes: this is the most ridiculous one, change for the sake of change. This usually is used for last, when we point something rational, they can't come up with anything better.

    - Java is old: curiously all "revolutionary" things are older than Java :).

    - Ruby is made for happines (sic): Rubyists are the only one happy people in the whole IT industry.

    Sorry, but RATIONALITY is what's missing in the whole discussion.

    I couldn't find ONE single Ruby developer with the necessary communication skills to pass the idea of what it would enable me to do in practical terms (not geeky talk). It all ends with "I'm better than you" kind of attitude.

    But I have to say, I think the most resistant to hype are usually the most intelligent ones because they are not following the herd and they are questioning the value of doing so.

    The herd goes BEYOND LOGIC.
  187. Recurrent patterns[ Go to top ]

    Part of the problem with this debate is that a lot of people seem to build their identity on what they do. I do not identity myself as a Java developer or a Smalltalk developer. I'm me, programming is just something I do. I try not to forget this.
    Not following your discussion with the other guy, but just noting a few things, not related exactly to what you're saying but interesting to make a point.I believe part of the problem is the inability of some to come with really good points on why Java is doomed. They base their whole argumentation on failed assumptions.Please note the recurrent patterns from Ruby zealots:- Java has nowhere to go from here: wrong assumption;- Java is web applications, so if Ruby takes over web applications (CRUD) Java is dead: wrong assertion;- This cool language feature is ALL we need: not true, a good platform is all developers need;- If you don't accept my words that means you're dumb (or have identity crisis as you said): this "superiority" rant I often find in Ruby zealots, who curiously didn't know what functional languages were before Brute Tate's book;- Open your mind: that means "Don't question, accept it blindly" :);- Everything changes: this is the most ridiculous one, change for the sake of change. This usually is used for last, when we point something rational, they can't come up with anything better.- Java is old: curiously all "revolutionary" things are older than Java :).- Ruby is made for happines (sic): Rubyists are the only one happy people in the whole IT industry.Sorry, but RATIONALITY is what's missing in the whole discussion. I couldn't find ONE single Ruby developer with the necessary communication skills to pass the idea of what it would enable me to do in practical terms (not geeky talk). It all ends with "I'm better than you" kind of attitude.But I have to say, I think the most resistant to hype are usually the most intelligent ones because they are not following the herd and they are questioning the value of doing so.The herd goes BEYOND LOGIC.
    You might find it strange - but I actually agree with most of what you've said.

    If everyone was a little more careful with their language, then maybe the debate would generate less heat and more light.

    Well said.

    Paul.
  188. We're going to hit a wall with concurrency soon, as the new parallel processors come out. Ruby is not it in that space, but if you've read much production Java code, a whole lot of it works pretty much by accident, so you know Java's not it in that space either.
    I disagree. Java is already in that space.

    What's even more fascinating is that Java entered it before that space even existed.

    Why?

    The JVM.

    Think about it. All the Java multi-threaded code that has been written these past ten years (pretty much unchanged since JDK 1.0) can magically become completely hyperthreaded on multicore CPU's. With no recompiling. All it takes is smarter JVM's.

    I am also predicting a complete clean up in the mobile area. Java ME has tremendous momentum, and it's accelerating. Sorry, it's jerking (if you didn't know, an increase in acceleration is called jerk :-)). Java even runs on Windows Mobile... now think about that for a second...

    Java is just getting started.
    So do we see a comeback of functional languages, like Erlang?
    You mean a "come", right? :-)

    Functional languages have never been popular outside academia.
    200K downloads in under a year is significant.
    It's only significant if the rest of the world stands still.

    It hasn't.

    It's a bit like saying that Mac shipments have gone up 5% this past year and omitting to say that PC shipments have increased 15%, meaning that Macs have actually lost market share.

    But I'll leave the for another sensationalistic thread on TSS :-)

    --
    Cedric
    TestNG
  189. Where RoR runs out, Java keeps on running[ Go to top ]

    And you do need to follow the buzz. 200K downloads in under a year is significant. (I think that's about right...)

    I really don't think it is. There have been more downloads than that for open source Solaris. Is there a buzz around Solaris that it is going to become the OS of choice for most situations? No.
    So my best guess is that Java is going to undergo a transition period very soon, where it's going to change from the language of choice, in general, to the language of choice for big enterprise. From there? Who knows.

    This statement puzzles me hugely. If it happened it would be one of the fastest turn-arounds in the history of computing: Java has only just become the language of choice for general use (and many would argue it isn't there yet). So, millions and millions of developers are going to abruptly abandon Java and switch to Ruby? For general use? Over what time period?

    Sorry, but I just don't accept this. Ruby has a long way to go yet in terms of tools and performance before it can become competitive with Java generally. Perhaps for a subset of web applications, perhaps, but not generally. You use the term 'niche' earlier in your post. I think that is appropriate.

    After all, there have already been some equivalent languages (like Smalltalk) that have been around for much longer than ruby that have better performance, tools and vendor support and they have had little impact. There is no reason why Ruby should fare better.

    I am not trying to be particularly defensive of Java - I like Ruby - but I just can't see any mechanism for such a transition to occur given the conservative and slow-moving nature of IT.
  190. What will Java cover[ Go to top ]

    I am not so sure if Java will be good for the real big enterprise stuff in the long term. I see some point in having two different programming languages there, one for writing components and one for glueing them together. Ruby could very well cover the second part, but it does not integrate easily with Java. And using C or C++ as system programming language has its disadvantages against Java. So we will see where this area is going. For quite a time it will remain pretty much Java dominated, just because of the necessary conservativeness in such environments.

    But I see another area, which is pretty much uniquely covered by Java today: mobile devices with J2ME. Off course, it is not Java (Java-SE), but Java-ME, a different language, different VM etc.

    But somehow in the vicinity of Java..

    It will take its time until someone establishes a competing VM and spreads it to all mobile devices or supports the restricted limited J2ME-VM. Maybe this issue will go away when mobile devices get more powerful. But not so soon.
  191. What will Java cover[ Go to top ]

    I am not so sure if Java will be good for the real big enterprise stuff in the long term. I see some point in having two different programming languages there, one for writing components and one for glueing them together. Ruby could very well cover the second part, but it does not integrate easily with Java. And using C or C++ as system programming language has its disadvantages against Java. So we will see where this area is going. For quite a time it will remain pretty much Java dominated, just because of the necessary conservativeness in such environments.But I see another area, which is pretty much uniquely covered by Java today: mobile devices with J2ME. Off course, it is not Java (Java-SE), but Java-ME, a different language, different VM etc.But somehow in the vicinity of Java..It will take its time until someone establishes a competing VM and spreads it to all mobile devices or supports the restricted limited J2ME-VM. Maybe this issue will go away when mobile devices get more powerful. But not so soon.
    Well worded and intelligent IMO. These are the issues facing most developers I believe too. I also agree that it is merely the conservative nature of businesses that means that Java is seen as the primary way of addressing these issues.

    There are other sectors out there and other technologies too that are innovating to tackle some of the issues you mention head on. For example I see the component issue as the biggest obstacle in enterprise development today. Linking components together with loads of XML just can't be the best way. We do need some type of dynamic "scripting" glue. In this regard the Croquet project has some interesting ideas:

    http://www.opencroquet.org/

    I can see something like Croquet taking off in amongst the Universities and the academic sector, with the business sector finally catching up years later - just like they did with the internet and the web.

    Thanks for the post, you've made a point that has been on my mind, but I just haven't been able to express.

    Paul.
  192. What will Java cover[ Go to top ]

    Hi All,
    Lost in the noise was this post by Karl Brodowsky. for me it sums up the issue:
    I am not so sure if Java will be good for the real big enterprise stuff in the long term. I see some point in having two different programming languages there, one for writing components and one for glueing them together. Ruby could very well cover the second part, but it does not integrate easily with Java. And using C or C++ as system programming language has its disadvantages against Java. So we will see where this area is going...
    For true "big" enterprise applications mutiple language implementation is very common. Language agnostic interfaces such as messaging (Tuxedo) and webservices (WSDL/SOAP) makes this possible.

    To date in such environments Java as been seen as primarily a web application technology - linking to back-end databases and back-end services. Some have suggested that Java is now moving into the datacenter and becomming back-end technology. My point is what is the ideal technology to cover front-end application development.

    Using an EAI approach, front-end applications are a relatively thin layer on top of back-end services. I feel that a dynamic language is much better suited to this role than Java.

    Imagine an enterprise repository of services that you can browse. You then "script" together these services dynamically into new applications using "ActiveService" (akin to ActiveRecord in Rails). Also you can automatically create default web presentations to these services (again akin to what happens today with Rails). Assuming that the required services exists your application development productively will greatly increase. This is the component model we have been promised for years.

    So what are the obstacles. Well in my opinion RoR is just an example of what is possible once you use a dynamic language. Ruby is likely to be successful simply because it looks like Java/C/C++ in the Same way that Java was immediately successful over Smalltalk simply becaused it looked like C/C++.

    At the minute Ruby and RoR only facilitate dynamic integration to databases, and whilst I agree with the DRY principle, personally I would rather define my domain model in Objects rather than in relational tables. Also currently Ruby and Rails has limited integration capabilities with back-end services - but with the growing popularity of Rails I can see this all changing very quickly.

    So that leaves the role of Java. If Ruby becomes the web technology of choice, then where is Java going? IMO Java technology has stagnated. EJB3.0 is just an attempt to catch up with established open source standards and JSF is "out-dated technology" even before commercial tools have been released.

    Java has performed a very good role as "application-glue", but I think that role will be challenged by dynamic languages that are better suited to it. So where next for Java?

    Well it could be the datacenter replacing Unix/C/C++ as some have suggested or Java could just become another legacy technology.

    Paul.
  193. What will Java cover[ Go to top ]

    I see some point in having two different programming languages there, one for writing components and one for glueing them together. Ruby could very well cover the second part, but it does not integrate easily with Java.

    In what way does it not integrate well? Compared to what other languages?
    Some have suggested that Java is now moving into the datacenter and becomming back-end technology.

    I had assumed that it had been there for years. Could you clarify what you mean?

    http://www.microscope.co.uk/Article138497.htm

    "Java flows from the browser to the datacentre"
    You then "script" together these services dynamically into new applications using "ActiveService" (akin to ActiveRecord in Rails).

    We have already discussed this here. I raised the issue of the potential fragility of such applications. Sorry, but repeatedly implementing the Ruby equivalent of the Smalltalk #doesNotUnderstand: methods does not count as making an application robust.
    Ruby is likely to be successful simply because it looks like Java/C/C++ in the Same way that Java was immediately successful over Smalltalk simply becaused it looked like C/C++.

    I would certainly not agree that Ruby looks like Java or C++, and it is well established that Java was not immediately successful over Smalltalk - it took years to get established in the areas where Smalltalk was successful.
    but with the growing popularity of Rails I can see this all changing very quickly.

    And what is the evidence that things can change quickly? Where is the evidence that Rails is growing dramatically in real commercial use (as against a lot of experimentation)?

    Dice.com jobs:
    J2EE: 6644
    Java: 13282
    PHP: 941
    Python: 647
    Ruby on Rails: 27
    So that leaves the role of Java. If Ruby becomes the web technology of choice.

    Almost no-one is suggesting that Ruby is going to become the universal web technology. PHP hasn't. Smalltalk hasn't. They have had plenty of opportunity to. Why should Ruby? There are more jobs out there for Smalltalk than for RoR!
    EJB3.0 is just an attempt to catch up with established open source standards

    What standards? You realise that EJB 3.0 was based on Hibernate and TopLink and JDO?
    and JSF is "out-dated technology" even before commercial tools have been released.

    What do you base that on? What is your definition of "out-dated"? Can you show me any other component technology that is cross-platform and pluggable and renders to multiple client presentation methods? If not, how can you say it is outdated? How can you say 'before commercial tools have been released' when there have been commercial tools around for some time?

    Sorry to generalise, but I am having a problem with your posts in that you seem not to be addressing specific points people who disagree with you raise, simply repeating the same viewpoints. For example, I have mentioned issues of long-term support of dynamic language. All you have come back with is the hope that everyone should use Agile approaches. They don't. You have not addressed issues raised here about performance of many dynamic languages. You keep insisting that Java is seen primarily as a web application language; neglecting phenomenally successful markets such as the mobile device area, and the significant use in other areas (client side, embedded devices etc.)

    Yet again... the static/dynamic language debate has been raging for decades. Ruby, Python, PERL and Smalltalk have been around for a very long time. Why should anything change now?
  194. What will Java cover[ Go to top ]

    You pose very good questions - My post was speculating on possible futures.

    I do not have a crystal ball - but percieve a trend towards dynamic languages. Karl seems to agree with me too. How exactly things will work out? Who knows.

    If you look at the latest book titles on Ruby, they emphasise Ruby's Agileness. The pragmatic programming lot are pretty clever and they know that claiming to save time and money are pretty good selling points.

    You are right I don't think change will happen overnight, but I have already been approached by an agent for an "Agile Ruby" position.

    We will have to wait and see, but there are strong arguments lining up in Ruby's favour. I think Bruce is being totally honest about his experience - and it doesn't surprise me.

    BTW. Scripting and "does not understand" is no different to "null pointer exception" or "runtime cast exception" or "no such class exception" or a number of runtime exceptions you can get in Java.

    The suggestion that the "correctness" of a program can be determined statically at compile time is totally false. The only way to know whether a program works is to run it. That is true whether you use a dynamic language or a static one.


    Proving correctness statically for a imperative language is impossible (I'm sure I learnt this at Uni when doing predicate calculus, something to do with loops - if I'm wrong I'm sure some one will let me know :^)). Hence my focus on unit testing and Test Driven Development in particular.

    Paul.
  195. What will Java cover[ Go to top ]

    If you look at the latest book titles on Ruby, they emphasise Ruby's Agileness.

    Yes, but as experience has shown, the ability of a language to be agile does not mean that developers will use it that way :)
    We will have to wait and see, but there are strong arguments lining up in Ruby's favour. I think Bruce is being totally honest about his experience - and it doesn't surprise me.

    I'm sure he is being honest. But, I still can't see what it is about Ruby that sets it apart from any of the other dynamic agile languages that have been around for decades. What are these strong arguments?
    BTW. Scripting and "does not understand" is no different to "null pointer exception" or "runtime cast exception" or "no such class exception" or a number of runtime exceptions you can get in Java.

    Indeed. And if we get such exceptions in Java we treat them as serious errors. If you get an unexpected method sent to an object in a dynamic language - perhaps as a result of someone changing a service - that is also a serious error. Having a dynamic language does not help you, as you seemed to suggest it would.
    The suggestion that the "correctness" of a program can be determined statically at compile time is totally false. The only way to know whether a program works is to run it. That is true whether you use a dynamic language or a static one.Proving correctness statically for a imperative language is impossible (I'm sure I learnt this at Uni when doing predicate calculus, something to do with loops - if I'm wrong I'm sure some one will let me know :^)). Hence my focus on unit testing and Test Driven Development in particular.Paul.

    No-one was saying that compile time checks prove correctness. They are merely an aid. An aid that is missing from dynamic languages. Focussing on unit testing can help cover the loss of this aid, but my view is that it can involve a lot more work, so you are losing the apparent coding speed advantage of a dynamic language. This is my view after having used static languages for nearly 30 years and dynamic languages for nearly 20.
  196. What will Java cover[ Go to top ]

    If you look at the latest book titles on Ruby, they emphasise Ruby's Agileness.
    Yes, but as experience has shown, the ability of a language to be agile does not mean that developers will use it that way :).
    Yes. In the same way that Java claims to be OO, but how many people use it thay way :^) - the developer is far more important than the language.
    We will have to wait and see, but there are strong arguments lining up in Ruby's favour. I think Bruce is being totally honest about his experience - and it doesn't surprise me.
    I'm sure he is being honest. But, I still can't see what it is about Ruby that sets it apart from any of the other dynamic agile languages that have been around for decades. What are these strong arguments?I don't see Ruby as particularly special either - In fact I've gone to some lengths to explain that what I am saying applies to dynamic languages in general. As a dynamic language it does seem to have some momentum at the minute.
    The suggestion that the "correctness" of a program can be determined statically at compile time is totally false. The only way to know whether a program works is to run it. That is true whether you use a dynamic language or a static one.Proving correctness statically for a imperative language is impossible (I'm sure I learnt this at Uni when doing predicate calculus, something to do with loops - if I'm wrong I'm sure some one will let me know :^)). Hence my focus on unit testing and Test Driven Development in particular.Paul.
    No-one was saying that compile time checks prove correctness. They are merely an aid. An aid that is missing from dynamic languages. Focussing on unit testing can help cover the loss of this aid, but my view is that it can involve a lot more work, so you are losing the apparent coding speed advantage of a dynamic language. This is my view after having used static languages for nearly 30 years and dynamic languages for nearly 20.
    I use a static langauge for most of my work (Java) and I write all of my code Test Driven. I woudn't code another way. The argument that not testing is some how faster is a fallacy.

    Have you tried TDD?

    Paul.
  197. What will Java cover[ Go to top ]

    The argument that not testing is some how faster is a fallacy.

    I as was not talking about "not testing". My point was that (in my experience) you need more testing under a language without static typing.
    Have you tried TDD?Paul.

    Of course. I use it.
  198. What will Java cover[ Go to top ]

    The argument that not testing is some how faster is a fallacy.
    I as was not talking about "not testing". My point was that (in my experience) you need more testing under a language without static typing.
    Have you tried TDD?Paul.
    Of course. I use it.
    Well if you use TDD, you will know that you only write production code once you've written a failing test. So whether you use a dynamic language or not you will write the same amount of test code.

    Paul.
  199. What will Java cover[ Go to top ]

    Well if you use TDD, you will know that you only write production code once you've written a failing test. So whether you use a dynamic language or not you will write the same amount of test code.Paul.

    No you won't, as there is simply more that you have to test, and there are things that are very much more difficult to test. Duck typing can hide a lot of horrors!
  200. What will Java cover[ Go to top ]

    Well if you use TDD, you will know that you only write production code once you've written a failing test. So whether you use a dynamic language or not you will write the same amount of test code.Paul.
    No you won't, as there is simply more that you have to test, and there are things that are very much more difficult to test. Duck typing can hide a lot of horrors!
    I don't understand - please explain.

    I use TDD with Java, Smalltalk and Ruby all the same way: RED-GREEN-REFACTOR.

    Paul.
  201. What will Java cover[ Go to top ]

    Well if you use TDD, you will know that you only write production code once you've written a failing test. So whether you use a dynamic language or not you will write the same amount of test code.Paul.
    No you won't, as there is simply more that you have to test, and there are things that are very much more difficult to test. Duck typing can hide a lot of horrors!
    I don't understand - please explain. I use TDD with Java, Smalltalk and Ruby all the same way: RED-GREEN-REFACTOR.Paul.

    IMO, duck-typing tends to assume that the implicit interface that the duck-typed on which the duck-typed object is based is stable.

    If infrequently invoked methods are changed or added to the implicit interface, and testing is the only way to validate that the duck-typed object really implements the interface, then code may fail for obscure reasons unless you are testing every codepath of both your code and the code relying on the duck-typed object.

    Basically it's the difference between knowing something and being confident in something. With explicit interfaces, you know when something changes because the compiler tells you. With implicit interfaces, you are relying on your tests to not only validate the behavior of your code, but that it correctly implements all those implicit interfaces.
  202. What will Java cover[ Go to top ]

    Well if you use TDD, you will know that you only write production code once you've written a failing test. So whether you use a dynamic language or not you will write the same amount of test code.Paul.
    No you won't, as there is simply more that you have to test, and there are things that are very much more difficult to test. Duck typing can hide a lot of horrors!
    I don't understand - please explain. I use TDD with Java, Smalltalk and Ruby all the same way: RED-GREEN-REFACTOR.Paul.
    IMO, duck-typing tends to assume that the implicit interface that the duck-typed on which the duck-typed object is based is stable.If infrequently invoked methods are changed or added to the implicit interface, and testing is the only way to validate that the duck-typed object really implements the interface, then code may fail for obscure reasons unless you are testing every codepath of both your code and the code relying on the duck-typed object.Basically it's the difference between knowing something and being confident in something. With explicit interfaces, you know when something changes because the compiler tells you. With implicit interfaces, you are relying on your tests to not only validate the behavior of your code, but that it correctly implements all those implicit interfaces.
    I think I understand you. I also see a related problem around metaprogramming. My policy is that in application code you shouldn't be doing anything clever. It is OK for frameworks to use clever tricks (on the assumption that they will get tested by the broader community), but application code should be simple. On this basis my test assertions for dynamic code are pretty much the same as the assertions I would use for static code.

    In fact perfoming TDD with a dynamic language has some advantages, one of which is that you can use the notifier to declare methods that you define in your tests (every time your test comes across a "does not understand"), and continue running the same test.

    Ron Jefferies as a real neat tutorial on TDD using Smalltalk. It's quite interesting:

    http://www.xprogramming.com/xpmag/BowlingForSmalltalk.htm

    If you're interested, I he also test drives the same example in C#, Java and Ruby, all on the same website. It won't surprise you that I think the Smalltalk solution is by far the most elegant (with Ruby a distant second) :^).

    Cheers,

    Paul.
  203. What will Java cover[ Go to top ]

    I think I understand you. I also see a related problem around metaprogramming. My policy is that in application code you shouldn't be doing anything clever. It is OK for frameworks to use clever tricks (on the assumption that they will get tested by the broader community), but application code should be simple. On this basis my test assertions for dynamic code are pretty much the same as the assertions I would use for static code.In fact perfoming TDD with a dynamic language has some advantages, one of which is that you can use the notifier to declare methods that you define in your tests (every time your test comes across a "does not understand"), and continue running the same test.Ron Jefferies as a real neat tutorial on TDD using Smalltalk. It's quite interesting:http://www.xprogramming.com/xpmag/BowlingForSmalltalk.htmIf you're interested, I he also test drives the same example in C#, Java and Ruby, all on the same website. It won't surprise you that I think the Smalltalk solution is by far the most elegant (with Ruby a distant second) :^).Cheers,Paul.

    I think this post sums up the negatives I see in using dynamic languages in large-scale projects:

    http://blog.360.yahoo.com/blog-L8FHhfglaafunnJdDw4-?p=237
  204. What will Java cover[ Go to top ]

    I think this post sums up the negatives I see in using dynamic languages in large-scale projects:http://blog.360.yahoo.com/blog-L8FHhfglaafunnJdDw4-?p=237

    We have two graduates using Ruby on our project and they are getting on fine. No signs of the fears drumed up in your article.

    People who have actually used dynamic languages tend to prefer them because of the speedy feedback and the strength of expression (I should say have used them in recent years, just in case Steve is listening :^)). It is like anything to start of with you have to learn new tricks, but after a while it becomes natural, like riding a bike.

    Incidently there is one strong advantage that dynamic languages have over static ones, because of late binding all of the meta information discarded at compile time with static languages is available at runtime. This has some profound consequences. Things like AOP, IoC etc can be done within the language, no need for byte code manipulation, special compilers and/or XML no need for special containers. Also your program can generate code on the fly dynamically, using meta data to write code for you while the program runs. This is what the Rails framework does, which is why Rails cannot be implemented in Java.

    The other consequence of this full reflectiveness is innovation. "Language designers" can experiment with new language constructs within the base programming language. In Java a lot of decisions have been fixed. Both JDO and Hibernate needed to resort to byte code manipulation inorder to extend the language capabilities. Another work around in Java is the use of external languages - like XML Mapping files and HQL (Hibernate query Language) for Hibernate. GLORP a Smalltalk ORM solution does the same as Hibernate all within Smalltalk. No cglib byte code manipulation, no XML no HQL.

    As a consequence of research new language features can be provided in the form of frameworks and libraries (or as Martin Fowler prefers to describe them internal DSL's). The continuation Server approach in Seaside is one such example. No need to change the base language.

    There is a lot of innovation occuring in Dynamic languages at the moment. Much of it leaving Java well behind. My preferred dynamic language is Smalltalk. Take a look at what is going on in the Croquet project. It is close to science fiction:

    http://am.mediasite.com/am/viewer/Viewer.aspx?layoutPrefix=LayoutLargeVideo&layoutOffset=Skins/Clean&width=881&height=648&peid=172f6de5-135b-4ba0-9207-ac6d383812c9&pid=fc503ef3-4a4e-44a6-b289-c915d8bf7bd3&pvid=502&mode=Default&shouldResize=false&playerType=WM64Lite

    Watching the video above is a lot easier than reading all the whitepapers on the Croquet website:

    http://www.opencroquet.org/

    If you haven't heard of Croquet before take the time to what the video. You will be amazed!

    Paul.
  205. Dynamic Fears and Trust[ Go to top ]

    I think this post sums up the negatives I see in using dynamic languages in large-scale projects:http://blog.360.yahoo.com/blog-L8FHhfglaafunnJdDw4-?p=237
    We have two graduates using Ruby on our project and they are getting on fine. No signs of the fears drumed up in your article.

    The question is: How much do you trust your fellow developers?

    My personal opinion is that the suitability of a staticly-typed language is inversely proportional to the team's understanding of the solution.

    Static typing is an optimization. It lets the compiler produce faster code. It lets the developer get more rapid feedback on how whether his code fits with the rest of the system. (does it compile? is my IDE underlinning it in red?)

    Having the compiler check the code is great if:
    1. There's tons of code
    2. You're not familiar with all the code
    3. The code isn't an amorphous blob

    But once your code is no longer an amorphous blob, static typing starts to get useful. Given enough code and a large enough team, I think it becomes essential. However, I don't think the average web application ever reaches this state. Small teams building small applications with rapidly changing requirements are pretty common.

    If you're requirements are rapidly changing, then your code probably is an amorphous blob, whether you like it or not.
  206. What will Java cover[ Go to top ]

    I think this post sums up the negatives I see in using dynamic languages in large-scale projects:
    We have two graduates using Ruby on our project and they are getting on fine. No signs of the fears drumed up in your article.

    Sorry, but I don't think that this is an adequate response to the article. There were clear points raised. They are about the use of dynamic languages like Ruby for general widespread use by teams. Just because they haven't yet happened to you does not mean that the points raised aren't valid. Do you accept the points, or do you have some technical reason why they aren't valid? Can you demonstrate some tests that would cover the issues raised in the article?
    Incidently there is one strong advantage that dynamic languages have over static ones, because of late binding all of the meta information discarded at compile time with static languages is available at runtime.

    Why do you think that meta-data included with static languages is discarded at compile time? XML metadata certainly isn't. You should look up things like the Java 1.5 @Retention annotation which allows you to specify when metadata is discarded.
    Also your program can generate code on the fly dynamically, using meta data to write code for you while the program runs.

    Java can do this: Javac is included at run-time, and you can use byte code generation. This is how Spring generates proxies and does AOP while the program runs.
    This is what the Rails framework does, which is why Rails cannot be implemented in Java.

    Sorry, but it could - either by code generation or byte-code manipulation. This is how other neat things (like continuations) are being done in Java.

    Of course, as we have already discussed (and you have not answered), having such things dynamically generated can potentially lead to serious code fragility. It is clever, but some of us think it is not wise.
    In Java a lot of decisions have been fixed.

    With good reason - so that there is a standard that every knows.
    Both JDO and Hibernate needed to resort to byte code manipulation inorder to extend the language capabilities.

    No, they don't. They aren't extending the language capabilities - they are simply adding additional methods to classes or proxying. Proxying is now a standard part of the Java language (since 1.3), and there has never been a requirement for byte code manipulation in JDO - enhancement is an optional facility.
    AAs a consequence of research new language features can be provided in the form of frameworks and libraries (or as Martin Fowler prefers to describe them internal DSL's).The continuation Server approach in Seaside is one such example. No need to change the base language.

    What is wrong with changing the base language?
    Much of it leaving Java well behind.

    This is false, as much of the 'innovation' was there well before Java was even invented. Java was designed with full knowledge of what the situation was with dynamic languages - Smalltalk predates Java by nearly 20 years.
     
    Take a look at what is going on in the Croquet project.You will be amazed!Paul.

    I have already (on another thread) pointed out amazing networked virtual worlds and interfaces implemented in Java.
  207. What will Java cover[ Go to top ]

    Hi Steve,

    I can see that you’re back to combative ways. The article was an opinion piece. I merely responded with my opinion in kind. But I'll try and address your points specifically...
    I think this post sums up the negatives I see in using dynamic languages in large-scale projects:
    We have two graduates using Ruby on our project and they are getting on fine. No signs of the fears drumed up in your article.
    Sorry, but I don't think that this is an adequate response to the article. There were clear points raised. They are about the use of dynamic languages like Ruby for general widespread use by teams. Just because they haven't yet happened to you does not mean that the points raised aren't valid. Do you accept the points, or do you have some technical reason why they aren't valid? Can you demonstrate some tests that would cover the issues raised in the article?
    OK. One of the tenants of Agile development is to value people over processes and tools. We do. We do not rely on compiler restrictions to enforce rules on developers. We do have team conventions and we do have agreed disciplines, but they are enforced socially and through peer pressure. We program in pairs, so some on is looking over your shoulder all the time no need for the compiler as watch dog approach. This works very well for us.
    Incidentally there is one strong advantage that dynamic languages have over static ones, because of late binding all of the meta information discarded at compile time with static languages is available at runtime.
    Why do you think that meta-data included with static languages is discarded at compile time? XML metadata certainly isn't. You should look up things like the Java 1.5 @Retention annotation which allows you to specify when metadata is discarded.
    I do not consider XML as part of the Java language. I also do not see annotations as a means of running external processors as part of the Java language either. They are just what they are - a means of running external XML processors (I think, this is correct, I'm not hot on annotations. Annotations are what made me finally give up on Java innovation and go in search of my old copy of the Purple Book (Smalltalk Bible) :^)). I see annotations as a ugly kluge (opinion again).
    Also your program can generate code on the fly dynamically, using meta data to write code for you while the program runs.
    Java can do this: Javac is included at run-time, and you can use byte code generation. This is how Spring generates proxies and does AOP while the program runs.
    Yes. Java does this. But it wasn't possible until the dynamic proxy API introduced in Java 1.3 I think. Do you know the hoops you have to jump through to generate an interceptor for a class (not an interface) in byte code? I consider this another ugly kludge and I'm sure if you speak to the people who have had to do it they would agree (again just my opinion).
    This is what the Rails framework does, which is why Rails cannot be implemented in Java.
    Sorry, but it could - either by code generation or byte-code manipulation. This is how other neat things (like continuations) are being done in Java.Of course, as we have already discussed (and you have not answered), having such things dynamically generated can potentially lead to serious code fragility. It is clever, but some of us think it is not
     wise.
    Well if you want to rely on one ugly kludge built on top of the next then that is up to you. When compared to the reflectiveness available in most dynamic languages, what you can do with the dynamic proxy API, the reflections APIs and cglib in Java is severely limited - this is not my opinion this is just plain fact. BTW byte code was never intended to be "programmed" by anyone - so anything using cglib is going beyond the scope of the Java language (my opinion). In dynamic languages such metaprogramming is rightly beyond the scope of application developers and should be the reserve of framework builders. How can you enforce this? – again through social convention.
    In Java a lot of decisions have been fixed.
    With good reason - so that there is a standard that every knows.
    Both JDO and Hibernate needed to resort to byte code manipulation in order to extend the language capabilities.
    No, they don't. They aren't extending the language capabilities - they are simply adding additional methods to classes or proxying. Proxying is now a standard part of the Java language (since 1.3), and there has never been a requirement for byte code manipulation in JDO - enhancement is an optional facility.
    The dynamic proxy interface allows proxies on Interfaces only. If you do not have an interface you need to create one, hence the need for byte code generation and cglib (after using the reflection API on the class to find out what the interface you need to generate should look like). So Dynamic Proxying for classes is not part of the Java language.
    As a consequence of research new language features can be provided in the form of frameworks and libraries (or as Martin Fowler prefers to describe them internal DSL's).The continuation Server approach in Seaside is one such example. No need to change the base language.
    What is wrong with changing the base language?
    Much of it leaving Java well behind.
    This is false, as much of the 'innovation' was there well before Java was even invented. Java was designed with full knowledge of what the situation was with dynamic languages - Smalltalk predates Java by nearly 20 years.&nbsp;
    I will take the above three points together:
    Smalltalk-80 as I understand it didn't support continuations, I don't think it fully supported proper closures. It used a limited form of block closures. Continuations as I understand it where introduced in the Lamda language (I'm not sure of this, and I'm not going to take the time to check). This aside AFAIK Seaside is the first use of continuations as a web server technology - sounds like innovation to me.
    Take a look at what is going on in the Croquet project. You will be amazed!Paul.
    I have already (on another thread) pointed out amazing networked virtual worlds and interfaces implemented in Java.
    I can tell that you still haven't looked at Croquet - if you had you would realise that your comparison is totally void. Hopefully someone else will take a look and come back and explain to you why (I think I’ve don my fair share of explaining :^)).

    Steve,

    I do not want to insult, but I do think you need to broaden your mind. There are lots of interesting things going on outside the Java world and all the people involved in them are not stupid. Spend some time exploring alternatives and reconsider your view. It seems to me that your stuck with an analysis you performed some years ago. Well the world's has moved on a bit since.

    Paul.
  208. What will Java cover[ Go to top ]

    Hi Steve,I can see that you’re back to combative ways. The article was an opinion piece.

    No, it gave an actual code example. I would suggest that to counter the argument you need to give an actual example of a test for the error.
    OK. One of the tenants of Agile development is to value people over processes and tools.

    As has already been discussed, not everyone uses Agile development. If you are saying you need agile development to make up for deficiencies in some languages, I agree.
    This works very well for us.

    Again, irrelevant. The article was about general use.
    I do not consider XML as part of the Java language. I also do not see annotations as a means of running external processors as part of the Java language either.

    Well annotations are, whether you think they are or not. Annotations don't need external processors. I don't use such processors for much of my use of them.
    How can you enforce this? – again through social convention.

    Sorry, but my experience is that this simply isn't good enough. Part of my job is to deal with code others have already written - I can't retrospectively apply 'social convention' to past development.
    The dynamic proxy interface allows proxies on Interfaces only.

    True, but you can do it with other libraries (ASM, CGLIB).

    You may wish to remember that there was not much code generation that could be done in many Smalltalk implementations, as you were not allowed to ship the compiler at runtime!
    This aside AFAIK Seaside is the first use of continuations as a web server technology - sounds like innovation to me.

    It is - but we are talking about far more than just continuations.
    Hopefully someone else will take a look and come back and explain to you why (I think I’ve don my fair share of explaining :^)).Steve,I do not want to insult, but I do think you need to broaden your mind. There are lots of interesting things going on outside the Java world and all the people involved in them are not stupid. Spend some time exploring alternatives and reconsider your view. It seems to me that your stuck with an analysis you performed some years ago. Well the world's has moved on a bit since.Paul.

    Don't worry about me - I am pretty resistant to insults!

    Just because I disagree with you, does not mean I am not keeping up to date. It is part of my job to explore alternatives. No-where did I say that others developing outside of Java are stupid. But - ideas that are innovative and exciting aren't always the best ideas to implement in the real world.

    Not everyone is working in the comfortable organised, planned, Agile world. For better or worse, we have to deal with the real situation for millions of developers. Simply saying 'do it in an agile' way is, frankly, unrealistic in many circumstances, and not a satisfactory answer, at least in my view.

    OK - I'll leave this topic alone for a while - enjoy the debate :)
  209. What will Java cover[ Go to top ]

    No-where did I say that others developing outside of Java are stupid. But - ideas that are innovative and exciting aren't always the best ideas to implement in the real world. Not everyone is working in the comfortable organised, planned, Agile world. For better or worse, we have to deal with the real situation for millions of developers. Simply saying 'do it in an agile' way is, frankly, unrealistic in many circumstances, and not a satisfactory answer, at least in my view.OK - I'll leave this topic alone for a while - enjoy the debate :)

    I'm going to skip all of Paul's misunderstandings about annotations and byte-code generation...

    Well, not completely...

    I mainly use annotations as markers and runtime metadata to drive AOP. The AOP processor sees the annotations and uses the annotation meta-data to weave in other services and features to the annotated classes. The meta-data isn't thrown away, and I don't have to write any processors.

    Ok, now back to the development process stuff...

    XP is usually advocated for smaller projects. Rails is (for now) being pushed for smaller projects. I have serious doubts about scaling both of these up... not that I don't like some of the tenets of XP, like TDD, but as a whole it doesn't seem like it would fit well in a large team... Oh, and I hate pairing... But anyway...

    The major force in software development that you're TOTALLY missing is offshoring. If you're not addressing how this can work with offshore resources, you've already missed the direction the boats going now. Like it or not, many if not most software projects in the coming years are going to have an offshore component (if they're not shipped overseas altoghether). We're doing it where I work, and it works ok if we give them manageable chunks and adequately spec what they need to do plus give them some examples in the code to work from.

    What wouldn't work is a very dynamic environment. They don't want it, and I can't blame them. They've got very rigorous and perscribed processes, but they're not exactly "agile". It's hard to have that back-and-forth communication across time, location, and language barriers. I have yet to see anyone from the XP camp lay out an offshoring policy, which, I think, will mean that anything that REQUIRES XP principles to be effective is going to have a hard time (like the way you're recommending to use dynamic languages). Mind you, for our work in the states, we use a very agile process (but no pairing, thank god), but it doesn't work when we send work across the ocean.
  210. What will Java cover[ Go to top ]

    I constantly feel like I'm having to defend myself here...

    OK, lets go again.
    I'm going to skip all of Paul's misunderstandings about annotations and byte-code generation...Well, not completely...I mainly use annotations as markers and runtime metadata to drive AOP. The AOP processor sees the annotations and uses the annotation meta-data to weave in other services and features to the annotated classes. The meta-data isn't thrown away, and I don't have to write any processors.
    I acknowleged that I'm not the sharpest penny on annotations. The meta data I was speaking of was the stuff inherent in the source code and that ends up in the AST during compilation. In a dynamic language extra layers of indirection means that method lookups and object lookups can be intercepted at run-time, they are not hard-wired at compile time. Hence you can do your AOP interception at run timewithout XML.
    Ok, now back to the development process stuff...
    Thanks.
    XP is usually advocated for smaller projects. Rails is (for now) being pushed for smaller projects. I have serious doubts about scaling both of these up... not that I don't like some of the tenets of XP, like TDD, but as a whole it doesn't seem like it would fit well in a large team... Oh, and I hate pairing... But anyway... The major force in software development that you're TOTALLY missing is offshoring.
    First of all, I'm not hear to tell everyone how they should develop code. I'm merely expressing my perspective and how a dynamic language would help me in my day-to-day work.

    Like I said before, many of the books on Ruby make refrence to it's supposed "Agileness". If you're not Agile then don't use it. I am.
    If you're not addressing how this can work with offshore resources, you've already missed the direction the boats going now. Like it or not, many if not most software projects in the coming years are going to have an offshore component (if they're not shipped overseas altoghether). We're doing it where I work, and it works ok if we give them manageable chunks and adequately spec what they need to do plus give them some examples in the code to work from. What wouldn't work is a very dynamic environment. They don't want it, and I can't blame them. They've got very rigorous and perscribed processes, but they're not exactly "agile".
    Again I'm not the spokes person for Ruby or for dynamic languages or even for Agile Development for that matter. I'm a Java developer just like the rest of you. I'm merely pointing out that in certain circumstances dynamic languages offer signifacnt advantages. I went to lengths to define 3-4 criteria where I felt the use of Ruby and RoR was well worth considering. Take a look back at my previous posts.

    I'm also offering an opinion that the scope of where dynamic languages like Ruby are applicable may easily grow, overlapling further with the ground of the "typical" J2EE web application (and I know that no one can define typical, which is why I offer it as an opinion and a suggestion for further debate).

    I'm not interest in India, or Outsourcing. You are right companies are being facing stark choices. You've got the "pile it high and sell it cheap" approach which is focused on outscourcing and India. And you've got the "more with less, work smarter" approach which I believe the Agile movement represents. Like I said it's all down to choice.

    If you want to move to India, that's up to you. What I am trying to do is provide better value to my clients right here in the UK. I think Bruce Tate is trying to do the same, whilst being honest to the community that gave him his breaks in the first place. That is my view.

    BTW:Agile can be scaled up to large projects (noticed I haven't said teams), but it does need a supporting management and organisational cutlure. There are many catalogued examples of this. If you want to know more read on Scrum.

    Paul.
  211. Hi,

    In my last post I think I miss-understood what was being referred to as XML meta-data (that's the problem with XML it's being used for everything :^)). I think both Steve and Jason was refering to the info that AOP uses to do it's advice weaving.

    Well as far as I can tell some Smalltalk AOP implementations need to the same thing although they tend not to use XML (I have done a google search and I've come across specific aspect defining languages for this purpose). I have also come across Smalltalk AOP implementations that define Aspects directly in Smalltalk.

    I'm still quite sure that AOP implementation is significantly easier in a dynamic language like Smalltalk than a static one like Java, but I wouldn't want to spread miss-information (at least not knowingly :^)).

    Paul.
  212. Hi,In my last post I think I miss-understood what was being referred to as XML meta-data (that's the problem with XML it's being used for everything :^)). I think both Steve and Jason was refering to the info that AOP uses to do it's advice weaving.Well as far as I can tell some Smalltalk AOP implementations need to the same thing although they tend not to use XML (I have done a google search and I've come across specific aspect defining languages for this purpose). I have also come across Smalltalk AOP implementations that define Aspects directly in Smalltalk. I'm still quite sure that AOP implementation is significantly easier in a dynamic language like Smalltalk than a static one like Java, but I wouldn't want to spread miss-information (at least not knowingly :^)).Paul.

    Who cares how hard it is to implement AOP? I'm not planning on implementing an AOP framework myself, and I thought this discussion was about developer usability and productivity?

    Speaking of innovation, AOP was invented for the Java platform by the AspectJ guys at Xerox Parc. Now they work on Eclipse tools that show you where the aspects will be applied to your code-base so you can have static analysis with the dynamic nature of AOP weaving.

    AOP is probably the next paradigm for development, building on OO, and it was invented on top of Java.
  213. <blocquote>Who cares how hard it is to implement AOP? I'm not planning on implementing an AOP framework myself, and I thought this discussion was about developer usability and productivity?Speaking of innovation, AOP was invented for the Java platform by the AspectJ guys at Xerox Parc. Now they work on Eclipse tools that show you where the aspects will be applied to your code-base so you can have static analysis with the dynamic nature of AOP weaving. AOP is probably the next paradigm for development, building on OO, and it was invented on top of Java.Good point. Some very good things have been done in Java. I for one was looking forward to mobile code and the promise of JINI and JavaSpaces, but Sun seemed to give up on them, chose to follow Microsoft down the WSD/SOAP SOA path. Why?

    I acknowledge that a lot of first have occured in Java. To me it feels like things have stagnated of late. I don't like JSF and I don't think EJB3.0 gives me anything new.

    Am I the only one that feels this way?

    Paul.
  214. To me it feels like things have stagnated of late. I don't like JSF and I don't think EJB3.0 gives me anything new.Am I the only one that feels this way?Paul.

    No, you're not the only one. But EJB3 only seems boring because it's just trying to catch up with the real innovation, which is going on in OSS (Spring in this case). JPA isn't anything new either, but at least it's standardizing the common interfaces for Hibernate / Toplink / Kodo so that we can choose based on implementation, now that they're all going to be free and OS.

    JSF, well... I have my own feelings on JSF... it usually ends up coming out including "design by committee", but I digress.

    Anyway, there is real innovation in the OSS side, it's just moved up to higher level APIs for "getting things done fast", for instance JSR-181 lets you tag classes and methods to have them automatically exposed as web services. XFire, a very slick web services library, can automatically read those annotations and expose the web services for you, even generating the schema to map to your datatypes.

    Similarly with annotations to declare transactionality in Spring and security using Acegi. All of this stuff makes people much more productive.

    There's lots of stuff like this. Unfortunately, my JavaOne talk about how my team has been gluing these OSS frameworks together to achieve great reuse and productivity got turned down :-(.
  215. blockquote>
    To me it feels like things have stagnated of late. I don't like JSF and I don't think EJB3.0 gives me anything new.Am I the only one that feels this way?Paul.
    No, you're not the only one. Good. I was beginning to think I was going mad.
    But EJB3 only seems boring because it's just trying to catch up with the real innovation, which is going on in OSS (Spring in this case). JPA isn't anything new either, but at least it's standardizing the common interfaces for Hibernate / Toplink / Kodo so that we can choose based on implementation, now that they're all going to be free and OS. JSF, well... I have my own feelings on JSF... it usually ends up coming out including "design by committee", but I digress.

    The words "design by comittee" come to mind for me too when it comes to JSF. I didn't know about JPA, but I can guess what it is, a standardisation for political reasons (keeping all the persistence API vendors happy).
    Anyway, there is real innovation in the OSS side

    I've come to put my hope in open scource too. Never really took it seriously before. But they seem to be the only guys out there actually trying to look out for my interests.
    it's just moved up to higher level APIs for "getting things done fast", for instance JSR-181 lets you tag classes and methods to have them automatically exposed as web services. XFire, a very slick web services library,... of this stuff makes people much more productive.There's lots of stuff like this. Unfortunately, my JavaOne talk about how my team has been gluing these OSS frameworks together to achieve great reuse and productivity got turned down :-(.
    Thanks for the OSS references I will look them up. I haven't used EJB's and a Application Server in over a year. The possiblities of WebServices made me look up BEA Weblogic earlier today. Well it isn't Weblogic anymore it's Aqualogic, and I couldn't see how the linked to the App Server and EJB's, Sevlets etc, because all the talk was about the their "SOA Bus".

    I really do think Sun have lost their way. Standards like JSF seem to serve one purpose and one purpose only. Create new opportunities for software vendors to sell us tools we don't want and we didn't as for. You definately do not want to "hand code" JSF, is the message I got when I ploughed through the volumeous JSF spec(s).

    I know I'm going to get bashed for saying this. But given that your OSS presentation was refused, I'm going to say it anyway. Outside OSS, what is going one really does feel like "Microsoft Style Software Development", lacking intellectual weight, focused on expensive GUI tools and geared to making "the Java Cartel" as much money as possible. All at the expense of the end client. No wonder our customers are looking at outsourcing to India to reduce costs.

    Very different from the early java days.

    Paul.
  216. What will Java cover[ Go to top ]

    Hi Steve,I can see that you’re back to combative ways. The article was an opinion piece. I merely responded with my opinion in kind. But I'll try and address your points

    What a piece of work. Disagreement with this guy == combative!
  217. JDO does bytecode-manipulation[ Go to top ]

    JDO does indeed change the bytecode of compiled .class-files.
    I do not know about hybernate.
  218. JDO does bytecode-manipulation[ Go to top ]

    JDO does indeed change the bytecode of compiled .class-files.I do not know about hybernate.
    Hibernate is better than JDO in this regard, it doesn't change byte code, but it does generate byte code (Interfaces) so that it can create dynamic proxies on bytecode classes.

    Paul
  219. JDO does bytecode-manipulation[ Go to top ]

    JDO does indeed change the bytecode of compiled .class-files.I do not know about hybernate.

    Sorry - couldn't resist a quick comment.

    No, JDO does not require changing the bytecode of compiled class files. All it requires (in JDO 1.0) is that classes implement the PersistenceCapable Interface. It is simply the case that changing bytecode ('enhancement') is one (very common) method of doing this. Other methods are automated source-level modifications. JDO 2.0 is different, and does not require that persistent classes implement PersistenceCapable, unless they wish to conform to the Binary Compatibility rules.
  220. proving correctness of a program[ Go to top ]

    It is at least sometimes possible to actually prove the correctness of a program. But it can be proved that it is not always possible to *automatically* prove the correctness of a program. The termination part of the correctness cannot be proved automatically. Just write a function f(P) returning true if and only if program P terminates and false otherwise in order to test if programm P terminates and then write

    program Q
      while (f(Q)) {
         // do nothing
       }
    }

    This one leads to a contradiction.

    So in short: The Java-compiler can no way guarantee that our programs are correct. At best it con find certain obvious bugs, but it is not really going very far with that either.
  221. proving correctness of a program[ Go to top ]

    It is at least sometimes possible to actually prove the correctness of a program. But it can be proved that it is not always possible to *automatically* prove the correctness of a program. The termination part of the correctness cannot be proved automatically. Just write a function f(P) returning true if and only if program P terminates and false otherwise in order to test if programm P terminates and then writeprogram Q&nbsp;&nbsp;while (f(Q)) {&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// do nothing&nbsp;&nbsp;&nbsp;}}This one leads to a contradiction.So in short: The Java-compiler can no way guarantee that our programs are correct. At best it con find certain obvious bugs, but it is not really going very far with that either.
    Thanks for this Karl,

    I've been spouting this assertion for a while based on a dim and distant memory. It is nice to have it comfirmend (well at least half confirmed :^)).

    PS. Make sure and watch the Croquet demo video if you can find the time (1hr36mins, but you get to see the guts in about 40mins). If you haven't come across Croquet before you really wil be amazed.

    Paul.
  222. Addressing specific points[ Go to top ]

    I will attempt to address the points:
    Why should Ruby? There are more jobs out there for Smalltalk than for RoR!
    No reason why Ruby - could be any one of a number of dynamic languages, Ruby is just so happens to be carrying some monentum at the moment.
    EJB3.0 is just an attempt to catch up with established open source standards
    What standards? You realise that EJB 3.0 was based on Hibernate and TopLink and JDO?
    EJB3.o persistence is primarilly based on Hiberante which in turn is based on TopLink. JDO up untill recently was a competing approach, I believe they are trying to merge them primarily for political reasons.
    and JSF is "out-dated technology" even before commercial tools have been released.
    What do you base that on? What is your definition of "out-dated"? Can you show me any other component technology that is cross-platform and pluggable and renders to multiple client presentation methods? If not, how can you say it is outdated? How can you say 'before commercial tools have been released' when there have been commercial tools around for some time?.
    There are better approaches to web development. I've looked at the JSF spec and it reeks of "design by committee". It is too big too complex and unoriginal. Incidently the most innovative web framework out there Seaside started life in Ruby. I believe that there is a continuation based framework like Seaside for Ruby too. As for component technology - JSF and XML templates are nothing compared to the real GUI components available in Seaside (and presumeably in the Ruby equivalent).
    For example, I have mentioned issues of long-term support of dynamic language. All you have come back with is the hope that everyone should use Agile approaches. They don't.
    If you have adequate test coverage and good clean design, I see no problem in maintaining dynamic code. I would advocate good test coverage for static languages too. This is not necessarily Agile, but Agile teams tend to apreciate this more than most.
    You have not addressed issues raised here about performance of many dynamic languages.
    If I had a penny for every time someone worried about performance i would be a rich man. In my experience performance issues are usualy due to poor design. Hard performance issues can be resolved a number of ways:
    1. Throw hardware at it - memory and CPU's are cheap knowadays. Just add more memory and more CPU's.
    2. Use a performant service - Why not implement the speed critical code as a network available service?
    3. Link in a performant library - The library could be a wrapper around code written in a performant language (I'm sure I mentioned how Croquet made use of the OpenGL C/C++ library).
    You keep insisting that Java is seen primarily as a web application language; neglecting phenomenally successful markets such as the mobile device area, and the significant use in other areas (client side, embedded devices etc.)
    Yes, true .. this is "theserverside" and I have focused on J2EE.
    Yet again... the static/dynamic language debate has been raging for decades. Ruby, Python, PERL and Smalltalk have been around for a very long time. Why should anything change now?
    Moores law. The hardware has got fast enough and cheap enough that the concerns about performance that you raise are no longer the overriding consideration. What is more important is the cost of development and time to market. The average PC today has more processing power than a 1970's super computer. Given that Smalltalk was devised in the seventies (on less than a super computer), it makes sense that performance on modern hardware is no longer a big issue.

    Paul.
  223. Addressing specific points[ Go to top ]

    I will attempt to address the points:
    Why should Ruby? There are more jobs out there for Smalltalk than for RoR!
    No reason why Ruby - could be any one of a number of dynamic languages, Ruby is just so happens to be carrying some monentum at the moment.

    I think the evidence is that it is more publicity than momentum, but I could be interpreting things wrong.
    and JSF is "out-dated technology" even before commercial tools have been released.
    What do you base that on? What is your definition of "out-dated"? Can you show me any other component technology that is cross-platform and pluggable and renders to multiple client presentation methods? If not, how can you say it is outdated? How can you say 'before commercial tools have been released' when there have been commercial tools around for some time?.
    There are better approaches to web development. I've looked at the JSF spec and it reeks of "design by committee". It is too big too complex and unoriginal.
    Not that this is the place for this, but you are just stating opinion here, not technical argument. Anyone can say 'complex' and 'unoriginal' and 'design by committee', but without actual technical points these are meaningless. I don't care if something is committee-designed or unoriginal. As a past struts user I find it far from complex. I have seen developers put together sites using JSF in minutes - so much for complex!
    Incidently the most innovative web framework out there Seaside started life in Ruby.

    I assume you mean Smalltalk.
    I believe that there is a continuation based framework like Seaside for Ruby too. As for component technology - JSF and XML templates are nothing compared to the real GUI components available in Seaside (and presumeably in the Ruby equivalent).

    Well, they differ in at least some ways - JSF has the ability to render different technologies and good multi-vendor support. Have you actually looked at JSF components in detail?
    If I had a penny for every time someone worried about performance i would be a rich man. In my experience performance issues are usualy due to poor design.

    Sorry, but having had personal experience of this issue I take real exception to this. There are some things that one can end up doing that can take real processor power. Parsing large XML data streams; manipulating images as part of content management; numerical work as part of a scientific resource site; calculation of product availability given large sets of criteria. To say that these could be efficiently implemented in Ruby (as currently implemented) 'with the correct design' is just sheer nonsense.
    Why not implement the speed critical code as a network available service?

    Ah, so you expect me to implement something like image processing, with the mass of data involved, as a networked service? So, a networked Ruby service would give me better performance?
    3. Link in a performant library - The library could be a wrapper around code written in a performant language (I'm sure I mentioned how Croquet made use of the OpenGL C/C++ library).

    Because, as we have discussed here before, mixed language solutions can be very messy. And, of course, using this argument negates your 'performance doesn't matter' argument below.
    Yet again... the static/dynamic language debate has been raging for decades. Ruby, Python, PERL and Smalltalk have been around for a very long time. Why should anything change now?
    Moores law. The hardware has got fast enough and cheap enough that the concerns about performance that you raise are no longer the overriding consideration. What is more important is the cost of development and time to market. The average PC today has more processing power than a 1970's super computer. Given that Smalltalk was devised in the seventies (on less than a super computer), it makes sense that performance on modern hardware is no longer a big issue.Paul.

    Yes - the same old arguments I have heard for 20 years. They were wrong then and they are wrong now. This is the same arguments that were used to implement ever-increasing applications using technologies such as Visual Basic, which then collapsed under the load.

    Time to market is irrelevant if your application grinds to a halt under the demands of everyday use. I have seen such situations, and I have had to fix them.

    Performance on modern hardware IS a big issue, and it will remain so. The demands of users for what applications are required to do easily matches what Moore's Law provides.
  224. Addressing specific points[ Go to top ]

    I will attempt to address the points:
    Why should Ruby? There are more jobs out there for Smalltalk than for RoR!
    No reason why Ruby - could be any one of a number of dynamic languages, Ruby is just so happens to be carrying some monentum at the moment.
    I think the evidence is that it is more publicity than momentum, but I could be interpreting things wrong.
    and JSF is "out-dated technology" even before commercial tools have been released.
    What do you base that on? What is your definition of "out-dated"? Can you show me any other component technology that is cross-platform and pluggable and renders to multiple client presentation methods? If not, how can you say it is outdated? How can you say 'before commercial tools have been released' when there have been commercial tools around for some time?.
    There are better approaches to web development. I've looked at the JSF spec and it reeks of "design by committee". It is too big too complex and unoriginal.
    Not that this is the place for this, but you are just stating opinion here, not technical argument. Anyone can say 'complex' and 'unoriginal' and 'design by committee', but without actual technical points these are meaningless. I don't care if something is committee-designed or unoriginal. As a past struts user I find it far from complex. I have seen developers put together sites using JSF in minutes - so much for complex!
    Incidently the most innovative web framework out there Seaside started life in Ruby.
    I assume you mean Smalltalk.
    No, I really do mean Ruby. The invetor of Seaside uses both Smalltalk (Squeak) and Ruby. From what I can see the two communities are quite close.
    Yes - the same old arguments I have heard for 20 years. They were wrong then and they are wrong now. This is the same arguments that were used to implement ever-increasing applications using technologies such as Visual Basic, which then collapsed under the load.Time to market is irrelevant if your application grinds to a halt under the demands of everyday use. I have seen such situations, and I have had to fix them.Performance on modern hardware IS a big issue, and it will remain so. The demands of users for what applications are required to do easily matches what Moore's Law provides.
    You may be right. Performance could turn out to be an issue for Ruby. Croquet (Squeak Smalltalk) which I have mentioned before manages to deliver a 3D presentation with no performance issues. IMO poor performance is usually a symptom of poor design. But we will have to wait and see what happens when there are more RoR apps out there.

    Paul.
  225. Addressing specific points[ Go to top ]

    and JSF is "out-dated technology" even before commercial tools have been released.
    What do you base that on? What is your definition of "out-dated"? Can you show me any other component technology that is cross-platform and pluggable and renders to multiple client presentation methods? If not, how can you say it is outdated? How can you say 'before commercial tools have been released' when there have been commercial tools around for some time?.
    There are better approaches to web development. I've looked at the JSF spec and it reeks of "design by committee". It is too big too complex and unoriginal.
    Not that this is the place for this, but you are just stating opinion here, not technical argument. Anyone can say 'complex' and 'unoriginal' and 'design by committee', but without actual technical points these are meaningless. I don't care if something is committee-designed or unoriginal. As a past struts user I find it far from complex. I have seen developers put together sites using JSF in minutes - so much for complex!Again, you are 100% correct - I don't like JSF, that is my opinion. I could go into a justifiaction, but I agree this is not the place.

    I think I've adressed all your specific points. Funnilly we tend to agree on most things (aside from performance and the future of dynamic languages :^)). As for the future I don't think either of use has a crystal ball.

    It was interesting to hear your view though.

    Regards,

    Paul.
  226. Addressing specific points[ Go to top ]

    Funnilly we tend to agree on most things (aside from performance and the future of dynamic languages :^)). As for the future I don't think either of use has a crystal ball.It was interesting to hear your view though.Regards,Paul.

    [Actually, I think dynamic languages have a good future. I personally think that they may well 'take off' this time, but I was after your reasons why - hence the somewhat combative style of debate!]

    Even though I seem to disagree fundamentally with many of your views, it is always interesting to debate - thanks.
  227. Integration of Java and Ruby[ Go to top ]

    I can see basicly two approaches for coupling of applications partly in language A and partly in language B (like A=Java B=Ruby or so):
    - tight integration by calling each other locally. This work s mostly between C or C++ on one side and Java or Perl or Ruby on the other side. Connecting Ruby and Java in this way is not trivial, but would be possibly by bridging with C.
    - loose integration via IPC, IO, TCP/IP or something like that. This works well for any combination of languages as long as they both support a common protocoll at sufficiently high level. So this one works very well for Java and Ruby.
  228. Integration of Java and Ruby[ Go to top ]

    I can see basicly two approaches for coupling of applications partly in language A and partly in language B (like A=Java B=Ruby or so):- tight integration by calling each other locally. This work s mostly between C or C++ on one side and Java or Perl or Ruby on the other side. Connecting Ruby and Java in this way is not trivial, but would be possibly by bridging with C.- loose integration via IPC, IO, TCP/IP or something like that. This works well for any combination of languages as long as they both support a common protocoll at sufficiently high level. So this one works very well for Java and Ruby.
    There does seem to be at least one more way. The people who came up with the picocontainer IoC framework have been experimenting with IoC "scripting" using something other than XML.

    IoC is all based on a creational pattern, so I think their approach may only allow the passing of data in one direction on component creation (Ruby -> Java), but I haven't looked into it in detail.

    Anyway here is the link:

    http://www.picocontainer.org/

    Paul.
  229. and whilst I agree with the DRY principle, personally I would rather define my domain model in Objects rather than in relational tables.

    I have seen both:
    - In JDO you define objects and let JDO create the tables for you.
    - Active record starts with the tables and lets Ruby create the objects for you.

    I can see advantages and disadvantages for both. I tend to prefer the second approach, just because the database is a big issue in enterprise applications and needs to be optimized and tuned, which is easier having full access to the data model as in the second approach. But if the database is lightweight enough to just keep going without too much support, the first approach can be attractive, because it concentrates all the development work in the application and its programming language.

    It might be an idea to do something equivalent to JDO for Ruby.
  230. and whilst I agree with the DRY principle, personally I would rather define my domain model in Objects rather than in relational tables.
    I have seen both:- In JDO you define objects and let JDO create the tables for you.- Active record starts with the tables and lets Ruby create the objects for you.I can see advantages and disadvantages for both. I tend to prefer the second approach, just because the database is a big issue in enterprise applications and needs to be optimized and tuned, which is easier having full access to the data model as in the second approach. But if the database is lightweight enough to just keep going without too much support, the first approach can be attractive, because it concentrates all the development work in the application and its programming language.It might be an idea to do something equivalent to JDO for Ruby.
    Hi Karl,

    To be honest I haven't used RoR long enough to really form a firm opinion either way(all I've done is the usual down load and play with it a bit). But like you say it would be nice to have the option either way. I'm sure that with time as the framework matures it will be provide this.

    In time I may find out that my existing preference based on my experience with Hibernate changes, after real world experience with something like RoR (even I find it a bit difficult adapting to change :^)). You are correct in asserting that relational data is generally seen as far more important to the business then the associated application source code.

    Paul.
  231. Active Record vs. JDO-like approach[ Go to top ]

    You are correct in asserting that relational data is generally seen as far more important to the business then the associated application source code.
    This is generally true. But it is silly, sad and short-sighted. Data is no good without information about what it is, what it does, how it relates, how it is used, how it is persisted and how/what in what situations. A relational database can only give you so much. And if you have a DBA who doesn't like RI, it gives you even less.

    Mark
  232. Active Record vs. JDO-like approach[ Go to top ]

    And if you have a DBA who doesn't like RI, it gives you even less.
    (I'm assuming RI == Referential Integrity)

    In which case you don't have a DBA. You have an impostor claiming to be a DBA.
  233. Bruce keeps going back to this 4mo vs. 2 days crap. If I was caught up putting in practice all of the patterns and xml heavy frameworks-- yeah, 4 months. Throw all that away and regress into scriptlets and simple OO-- 2 days. If anything, the community is consuming itself with a bunch of cancerous solutions. Nothing is perfect (not even our MVC landscape), but there's a heck of a lot more opportunity in Java to go much further than the cop-out, "well, RoR great for *simple* applications"
  234. Err - parenting[ Go to top ]

    My wife and daughter found your writeup on the bile blog when they were just googling for her dad's name. Not cool.

    If your daughter is a teenager she probably already thinks you are the stupidest person on the planet. Its hard-wired into their brains you know.

    Besides, you could use Hani's post as a teaching experience:
    "You see honey, there are people in the world who are a-holes..."
  235. Err - parenting[ Go to top ]

    My wife and daughter found your writeup on the bile blog when they were just googling for her dad's name. Not cool.
    If your daughter is a teenager she probably already thinks you are the stupidest person on the planet. Its hard-wired into their brains you know.Besides, you could use Hani's post as a teaching experience: "You see honey, there are people in the world who are a-holes..."

    +1.

    All negativity aside, this is the funniest thing I've read for a while. I wonder if we can get back to the discussion at hand though....

    I think any prediction of the death of Java is premature. The same goes for Elvis (been to Vegas lately?). Besides, Java "died" once already: its original goal as a free-the-world-from-Microsoft silver bullet certainly didn't pan out.

    After that all Java ended up doing is dominating server-side processing and cell phones. A shame really, that first death. Maybe this second death will end up being the rebirth of Java on the client side :)


    Peter
  236. Err - parenting[ Go to top ]

    Maybe this second death will end up being the rebirth of Java on the client side :)Peter
    Most definitely.

    So I wonder how many lifes Java has? Maybe the 1.5/5.0 code name (Tiger) is an indication. About 9?
  237. Err[ Go to top ]

    As for the JCP being ineffective, The JCP *is* inneffective for the most part.
    Sorry, Bruce, this is just as silly as saying that research or science is silly because 99% of these projects never go anywhere.

    The JCP enabled an industry that represents billions of dollars in revenues every year. I will be very surprised if Ruby ever comes close to even one tenth of that.
    JRuby might get there anyway. You can certainly use it to drive your testing today, and live products already use it for things like scripting.
    Nonsense. Everybody knows that the only sane way to test these days is... TestNG. :-)

    --
    Cedric
  238. I have to say RoR is a absolutely good technology in Web development. Quickly and easily and efficially. But when we reture to that time that EJB was borned, we will found not yet, at lease this few years. J2EE/J2SE/J2ME and many many JXXX, no one can easily remove these.

    Jimmy
    itperson.blogspot.com
  239. "Err" ... Bruce, don't waste your time.[ Go to top ]

    Come on, buddy. There are people who actually know something and who should be listened to, and then there are the ones who just crave attention and will scream insults and obscenities to get it. When you try to get them to, you know, have manners --- like a normal human being --- you're pumping a dry well. So in which category do you suspect Hani would be found? Don't let people like that get you down. Just ignore them. They have nothing to contribute.

    Now watch him or one of his wanna-bes unleash The Terrible Power Of Bathroom Humour on me. Oh boy I'm scared now.
  240. Err[ Go to top ]

    U should see these guys when they give tech talks. These self-appointed gurus are so full of themselves man! Sell books, tech seminars... there exists a whole breed of such "gurus" who make predictions. Often people complain that his are the most boring tech talks. Raving and ranting about how in his crystal ball he sees end of java and all that.

    I wish people like Bruce would stop talking crap. If u dont like Java Bruce go on have fun with Ruby or whichever u'r mind pleases.
  241. Err[ Go to top ]

    [..] one of those guys (a bit like Jason Hunter, while we're dropping names) who thinks that writing a book means that his opinion is worthwhile and should be taken seriously for all eternity.

    A lot of people feel that way without even writing a book ..

    Guglielmo

    Enjoy the Fastest Known Reliable Multicast Protocol with Total Ordering

    .. or the World's First Pure-Java Terminal Driver
  242. PO-TATE-TOES

    Boil 'em, mash 'em, stick 'em in a stew !

    Bruce Tate IS a spooge receptacle.
  243. Err[ Go to top ]

    +1

    Java is not dead - Bruce Tate's brain is long time ago. For a couple of years (more more) he ran out of ideas to write "Bitter Java <XYZ>" books, he it has been proven that he does not know how to write "Sweet Java <XYZ>" book - he tried to write about Spring framework last year but failed miserably.
  244. Err[ Go to top ]

    lol Bruce is so left-brained. He'll never get it.
  245. Err: Left brain; Right brain[ Go to top ]

    lol Bruce is so left-brained. He'll never get it.

    I am not sure I see how this relates.

    While researching the differences between right and left brained, I found this survey.

    http://www.blogthings.com/rightorleftbrainedquiz/

    According to the above I am (the summary describes the sides of the brain):
     
    You Are 55% Left Brained, 45% Right Brained
    The left side of your brain controls verbal ability, attention to detail, and reasoning. Left brained people are good at communication and persuading others. If you're left brained, you are likely good at math and logic. Your left brain prefers dogs, reading, and quiet.

    The right side of your brain is all about creativity and flexibility. Daring and intuitive, right brained people see the world in their unique way. If you're right brained, you likely have a talent for creative writing and art. Your right brain prefers day dreaming, philosophy, and sports.

    So how would Bruce being left-brain hurt or help his position? Please explain.

    I am looking for some insights to your logic.
  246. Let us stay fair[ Go to top ]

    I do not understand why it is necessary to write in such a ridiculous style.

    I know that tss is a *Java*-site. And should remain one.

    But what is wrong in once in a while comparing Java with other stuff. This can only be done seriously if you are really open for arguments for the other side. Bruce is making some good points. He can be right or wrong or partly right or partly wrong... So what. It is an enrichment for the Java-community to seriously consider these ideas.

    What is wrong if some people go both sides? Java is not a religion. It is a tool. That you use when it is adequate. And don't use, when it is not adequate.

    Even for someone who does mostly Java stuff in the long run, it is a good idea to try out some other stuff, to extend the mind. You become a better Java developer by learning another programming language and environment like once a year or so. This gives new ideas and new capabilities. And it helps talking with people who do interfaces with the other language.

    It helps when the issue comes up and it needs to be discussed, which way to go on. How do you want to lobby for Java if you do not care to understand the alternatives?

    So without any intention to give up Java for good, I apreciate contributions like Bruce's very much.
  247. Let us stay fair[ Go to top ]

    But what is wrong in once in a while comparing Java with other stuff.

    But that already happens.
    Java is not a religion. It is a tool. That you use when it is adequate. And don't use, when it is not adequate.

    Actually, I think Java is far more than just a tool. It is a platform that has significantly changed the way that development and deployment of applications is done.
    How do you want to lobby for Java if you do not care to understand the alternatives?

    But that is not what is happening, is it? We are getting articles here which contain phrases like "Java: Dead...". I'm sure Bruce's message was far more complex, but the way things are phrased on this site, anyone would think that there was some major crisis with Java; that Java use was plummeting and we should all be looking for alternatives.

    I think it would be helpful if there were articles here which discussed the future of Java in a less dramatic way.... I am getting somewhat tired of what we British call 'Tabloid' headlines here.
  248. Yawn[ Go to top ]

    Is this really news? Without knowing the full context, the statement "spending 4 months on a project" is a bit useless. I haven't worked on WebUI in a long time, but when I did, things rarely took 4 months. If it took four months, it means the planning sucked. Anyone know what the context of that statement and what kind of environment produced that result?

    peter
  249. Yawn[ Go to top ]

    Is this really news?

    No. Java is still in its growth phase, with new areas of adoptions and new ideas. It has only just become the market leader in some aspects of IT, and I think it has a long life ahead of it, especially as the foundation and platform for a wider range of languages.

    Do we really have to have such negatively headlined articles on TSS? It seems little more than an attempt at sensationalism to me.
  250. Yawn[ Go to top ]

    Do we really have to have such negatively headlined articles on TSS? It seems little more than an attempt at sensationalism to me.
    IMO, This site has no credability, it discredits itself with low content quality, it crashes too many times, so if you post here then you must know rules.
  251. re-read the article[ Go to top ]

    ok, I re-read the article and I still can't tell why "the project" was stuck for 4 months. I'm totally guessing here, but it sounds like the developers were stuck in a rutt. The medicine for their rutt was to use a different language and framework.

    My question is this. Why were they stuck in a rutt and failed to see the "real problem"? Is it because people develop habits and have a hard time criticizing themselves? It would be nice to have much more information about the context which produced that situation.

    peter
  252. re-read the article[ Go to top ]

    ok, I re-read the article and I still can't tell why "the project" was stuck for 4 months. I'm totally guessing here, but it sounds like the developers were stuck in a rutt. The medicine for their rutt was to use a different language and framework.My question is this. Why were they stuck in a rutt and failed to see the "real problem"? Is it because people develop habits and have a hard time criticizing themselves? It would be nice to have much more information about the context which produced that situation.peter

    I've heard this story about the stuck Java project moved to RoR before, and what I never understood was...

    If they were working on it for four months, why did they have to spend a night building the data model? Didn't you HAVE a datamodel after four months? What did you start with, the GUI widgets?
  253. re-read the article[ Go to top ]

    If they were working on it for four months, why did they have to spend a night building the data model? Didn't you HAVE a datamodel after four months? What did you start with, the GUI widgets?

    That would be an interesting thing to know.

    Maybe they could never agree on a data model...fighting with the DBAs or something like that. So they built the application with RoR and then declared the DBAs couldn't change it because that would break all their code, and Ruby doesn't have any real refactoring tools.
  254. bs[ Go to top ]

    <blockquoteI've heard this story about the stuck Java project moved to RoR before, and what I never understood was...If they were working on it for four months, why did they have to spend a night building the data model? Didn't you HAVE a datamodel after four months? What did you start with, the GUI widgets?
    That was one point that caught my eye immediately.

    What has the implementation language (or 'platform', for the salesliars among us) got to do with the data model ?

    My guess is that this little oft-repeated story about the four months vs. two days is simply a lie. It's possible that the team could be incompetent, but I find that hard to believe.

    I enjoy flame wars, personally, so I liked this thread. I am a software developer, myself, and I could care less what the language is. Obviously J2EE will not be replaced by a scripting language, but the scripting language may well be useful. I use JavaScript all the time in Web apps, for instance, and would hate to be without it.

    As for betting whether more people would like Hani or The Tater to leave Javaland ... I'll take that bet ! Hani loves Java and has a commitment to the health of American business. He'll be driving forward long after the trendgoofs fade away. And innovations like 'asshat' are hard to do without ;-)
  255. Java: Dead Like COBOL, Not Like Elvis?[ Go to top ]

    It's amazing to me how much negative reaction there is to the subject of Ruby on Rails within the Java community. I think Bruce has discovered what you can't say in the Java community. One thing I do agree with in this thread is Ilya's point that Ruby on Rails seems to be kind of kludgy to set up for a production system. That is a problem that I think we can all agree will get solved easily over time. Remember, at some point in Java all we have was Tomcat 1.0, no WebSphere, WebLogic, Resin, JBoss, etc. Other than that, to people who seem to be viamently defending Java, what are you so afraid of? I think if you take the time to look at Ruby on Rails, start building some web apps with it, you will see that there are things about it that are just better than with Java. I'm not going to go into all the details here, but there many nice things about it. At a minimum, learning Ruby on Rails will make you a better programmer. If Ruby does one day take over Java, then so be it. It's not happening tomorrow or even this year, but why is the idea of that so offending to Java developers?
  256. Java: Dead Like COBOL, Not Like Elvis?[ Go to top ]

    It's amazing to me how much negative reaction there is to the subject of Ruby on Rails within the Java community. I think Bruce has discovered what you can't say in the Java community. One thing I do agree with in this thread is Ilya's point that Ruby on Rails seems to be kind of kludgy to set up for a production system. That is a problem that I think we can all agree will get solved easily over time. Remember, at some point in Java all we have was Tomcat 1.0, no WebSphere, WebLogic, Resin, JBoss, etc. Other than that, to people who seem to be viamently defending Java, what are you so afraid of? I think if you take the time to look at Ruby on Rails, start building some web apps with it, you will see that there are things about it that are just better than with Java. I'm not going to go into all the details here, but there many nice things about it. At a minimum, learning Ruby on Rails will make you a better programmer. If Ruby does one day take over Java, then so be it. It's not happening tomorrow or even this year, but why is the idea of that so offending to Java developers?

    I agree, it's offending, and I might know the reason. Most developers, though they might love their job as a developer, are somehow insecure. They are scared that if the language they are experts in goes away, or even shrinks in market share, they won't be as competitive in the market, and might either have a hard time finding a job and/or settle for less pay. This is BS, because good programming, design, architecture principles is what truly matters. I'd take someone with great OO design skills and no knowledge of some language before someone with knowledge of the language inside out (the core) and weak OO skills. I think learning knew technologies, will make us all better at what we do. If you learn some great way of doing something "The ruby way", maybe you and others will eventually turn it into a design pattern in Java, which will benefit us all.

    As far as Ruby's deployment platforms, it's only a matter of time, until some company and/or OS project jumps on the bandwagon. But I think there should still be some standardization, whether by a formal committee and/or by the community.

    Ilya
  257. Java: Dead Like COBOL, Not Like Elvis?[ Go to top ]

    It's amazing to me how much negative reaction there is to the subject of Ruby on Rails within the Java community. I think Bruce has discovered what you can't say in the Java community. One thing I do agree with in this thread is Ilya's point that Ruby on Rails seems to be kind of kludgy to set up for a production system. That is a problem that I think we can all agree will get solved easily over time. Remember, at some point in Java all we have was Tomcat 1.0, no WebSphere, WebLogic, Resin, JBoss, etc. Other than that, to people who seem to be viamently defending Java, what are you so afraid of? I think if you take the time to look at Ruby on Rails, start building some web apps with it, you will see that there are things about it that are just better than with Java. I'm not going to go into all the details here, but there many nice things about it. At a minimum, learning Ruby on Rails will make you a better programmer. If Ruby does one day take over Java, then so be it. It's not happening tomorrow or even this year, but why is the idea of that so offending to Java developers?
    I agree, it's offending, and I might know the reason. Most developers, though they might love their job as a developer, are somehow insecure. They are scared that if the language they are experts in goes away, or even shrinks in market share, they won't be as competitive in the market, and might either have a hard time finding a job and/or settle for less pay. This is BS, because good programming, design, architecture principles is what truly matters. I'd take someone with great OO design skills and no knowledge of some language before someone with knowledge of the language inside out (the core) and weak OO skills. I think learning knew technologies, will make us all better at what we do. If you learn some great way of doing something "The ruby way", maybe you and others will eventually turn it into a design pattern in Java, which will benefit us all.As far as Ruby's deployment platforms, it's only a matter of time, until some company and/or OS project jumps on the bandwagon. But I think there should still be some standardization, whether by a formal committee and/or by the community.Ilya
    I've been reading threads in theserverside for quite sometime. I don't remember seeing Ilya until quite recently. But I have to say, I've noticed you are one the consistent ones who post well thought out and sensible comments. Glad to have you here.
  258. Java: Dead Like COBOL, Not Like Elvis?[ Go to top ]

    I've been reading threads in theserverside for quite sometime. I don't remember seeing Ilya until quite recently. But I have to say, I've noticed you are one the consistent ones who post well thought out and sensible comments. Glad to have you here.

    Thanks, I've had more time lately to follow and post. Working on one project vs. the usual 5+ at a time.

    Ilya
  259. minor nit[ Go to top ]

    It's not a huge point, but WebSphere, WebLogic, and Resin have all been around longer than Tomcat.
  260. minor nit[ Go to top ]

    Scott, I'd love to see Ruby on Rails support in Resin. I know you have PHP support in Resin now, but if you can make production quality deployment of Ruby on Rails easy, people might find that helpful. Especially Java developers who are used to working with the ease of Resin, where you just download it, untar it, ./configure, make, make install are you are going. The Apache/FastCGI setup, or learning yet another web server (lighttpd) is kind of a pain.
  261. Other than that, to people who seem to be viamently defending Java, what are you so afraid of? I think if you take the time to look at Ruby on Rails, start building some web apps with it, you will see that there are things about it that are just better than with Java.

    I code in both, and I'm about ready to start writing really nasty replies to articles like this. Why, because I'm in this fourm to read about Java and I don't want to read a bunch of stupid out of context, generally unconstructive crap about some other langauge. When I'm on theserverside.com I don't want to read about why C# is so great or how Ruby is so easy to use. I'm not hear for that and generaly the ruby fan boys that comment here are almost never constructive.

    A big part of that is the fact that TTS has a problem with needing to post flame bait articles and I'm really f#$%ing tired of that too.

    I have the same inverse feeling when I'm on a ruby or c# fourm. I don't want to read a bunch of stupid crap from trolling Java developers, acting the same way that ruby developers do on this fourm.

    I agree with Hani in part. If you don't like Java anymore or are not offering something constructive get the hell out of here. If you programing in many langauges then a like parts of some better then other great, keep it constructive, or keep it to yourself.

    If you are on TTS and you don't like java or think java is dead, then please leave, or at least make your posts funny.
  262. reaction[ Go to top ]

    Well i think the negative reaction is because in almost all articles i see related to RoR that is published to the Java community, it always try to leverage on some sort handicap in Java to promote RoR. If RoR is so good, why does it just promote itself. This article is a prime example. I've also seen some good RoR articles on Linux/Developer mags, those are the better ones because it doesn't start with "Java <insert lame remarks here to promote RoR>" statements.

    I'm sure RoR is great for what its doing, probably better than Java also. But do say the whole Java language is dying/dead/useless just because some other language is better at doing/solving some specialized problem is just asking for it.
  263. Java: Dead Like COBOL, Not Like Elvis?[ Go to top ]

    Hi Paul,

    my guess is that what troubles the Java community is not what Mr Tate says, but the rationale behind his comments. Mr Tate wants to sell his books. Nothing wrong with that, either. But thrashing a programming language ecosystem (which he had absolutely no problem using for his personal and professional goals earlier) just to further his book sales is a thing that -- from my point of view rightfully -- draws critique; the more so when Mr Tate is not talking about advantages and disadvantages of both J2EE and RoR, but (to get attention, to be sure) about one of the systems being dead, which obviously is just a lie.

    Now, I am far from saying that Mr Tate is wrong on all counts, and I have defended his viewpoints on elephants etc. earlier, but the way he does lie so blatantly, and his reason for doing so, explain why some Java fanboys react that hotly to Mr Tate's utterings. Like Pavlov's dogs to a stimulus, the respond to Mr Tate's provocations by reiterating the same old dogmas without validating them against the truth, which is clearly no better that Mr Tate's agitation, but at least not as offensive.

    Mr Tate seems to know that proclaiming to use the right tool for the job would be a much more sensible and agreeable position. But guess why he still keeps on with the cheap atrocity propaganda? Yeah, right.

    Ruby and Rails both are cool. So is PHP. But lying and mounting a campaign for personal profit are, from the communities viewpoint, not. But that is not your problem, it is and will be the one of Mr Tate. In Germany, we have the saying: "Ist der Ruf erst ruiniert, lebt es sich ganz ungeniert." (You needn't worry if you've no reputation to lose.) I for one will welcome the times when noone will listen to mountebanks of Mr Tate's caliber anymore, and people will continue to produce good software with the right tools unhindered by zealotry and bigotry.

    Cheers, Lars
  264. Java: Dead Like COBOL, Not Like Elvis?[ Go to top ]

    ...just to further his book sales is a thing that -- from my point of view rightfully -- draws critique; the more so when Mr Tate is not talking about advantages and disadvantages of both J2EE and RoR, but (to get attention, to be sure) about one of the systems being dead, which obviously is just a lie.

    You're making a whole lot of assumptions here, few of which are remotely true. It would have been much easier for me to write another Java book, and continue to build my Java client list. Just in case you're interested, here's where I'm coming from:

    First, few people make much money on technical books. I certainly don't. You might be surprised to learn that most authors make less than 10%, sometimes, as little as 5% of the listed cover price per book. I'd make more flipping burgers. So the theory that an author with 3 java one best sellers in 4 years would cut himself off at the knees by alienating his customer base to make a whole lot of money on one controversial book doesn't hold a whole lot of water.

    Second, my notion that Java is "dead" is a misrepresentation. I use the "dead like cobol not like elvis" line often, to point out the opposite, when someone asks me something like "So you wrote Beyond Java. Is Java dead, then?" Cobol is still thriving in 2006, and Java will continue to live on and thrive long after 2006. I'm merely saying that Java's run at the top is limited, and it won't always have industry-leading mind share that it's got right now. Surely you can see that things like Rails, Lamp, and .NET are cutting into that mindshare. Others will follow. It's inevitable.

    Third, I didn't seek out Vance to do an interview. He called me, and I told him my honest opinions. I've been shutting down my Java-based blog, and reducing my time on TSS (except when posts like this one come out) because the time spent here is not constructive for me or my business. It's too politically charged to offer real discussion. I'll still do interviews as people want them, because I take my responsibilities as an author in this community seriously. And I'll still continue to promote Spring and Rife because I believe in the projects and the leadership behind them.

    Fourth, I've decided that the most constructive thing to do with the Java community is to point out things that dynamic languages and frameworks do well, and shed attention on how they might be accomplished in Java. I'll be dong a series at IBM developer works called crossing borders along those lines, where I show Java developers how things are done in dynamic languages, and some of the ways that they might seek to do the same kinds of things in Java.

    If you ever make it to Austin, look me up for a beer. You might be surprised on how much we agree.
  265. I have tried RoR motivated by the productivity gain claims by people like Bruce and Dave Thomas.
    I believe that the biggest productivity gain is not from Rails or Ruby per se, but from the fact that you can immediately execute the code you have written or generated, without having to restart the web server or to redeploy the application.
    The code, compile, deploy, test cycle is very compact. I loved the instant gratification and not having to wait to verify my changes.
    Am I the only person that finds it aggravating to have to redeploy your Java web application each time you add one little method to a class?
    This is an area where Java has regressed. As far back as five years ago IBM VisualAge allowed you to add/remove/modify methods and instance variables in a running system. It was delightful.
    Every time there is a new release of Java I expectantly look for this capability to come back, but it never does. I am not holding my breath for Mustang.
    I hereby propose that the next version of Java be called Clydesdale. It can haul lots of beer a long way. Just don't expect it to still be cold once it gets there.
  266. It is not Java's fault ![ Go to top ]

    I have read Lighter, Faster, Better, Simpler Java from the same author and I love his attitude toward the wrong things people have done with the Java language. In the top of this list, Struts and EJB holds a very strong position of the worst of the worst in the Java world. But that's not Java's fault. If people want to do things very, very complicated like EJB or very, very boring like Struts with Java, they will keep on doing it. Either with Java, Ruby or anything else. Any OO language can abstract the complexity of the most common and repetitive tasks of any web project, but as always people tend to focus on power and forget about simplicity or KISS (keep it simple stupid). Before you think Java is not suitable for web applications, I suggest you try Mentawai or Rife. I believe Ruby and Rails is the next big thing for very simple and small projects. There is no way you can compare Active Record with Hibernate or how you can use page conventions for a big project. Beyond passion there is rationality. I am still in love for Java, but the passion days are over.

    So before you jump to RoR because you are tired of Struts, XML, WW, Spring, etc, take a look in a much simpler, pragmatic, joyful solution to web development. PROGRAMATIC CONFIGURATION IS THE SALVATION !!!

    http://www.mentaframework.org/
  267. Personal attacks are not cool ![ Go to top ]

    My wife and daughter found your writeup on the bile blog when they were just googling for her dad's name. Not cool.
    If your daughter is a teenager she probably already thinks you are the stupidest person on the planet. Its hard-wired into their brains you know.Besides, you could use Hani's post as a teaching experience: "You see honey, there are people in the world who are a-holes..."
    I don't agree with a post like that. If you don't agree with Bruce's point of view, you should come back with arguments, not this kind of post. I think TSS should ban and moderate this forum to avoid this kind of behaviour from users that do not know how to participate in a community.

    Anyways, whoever read Bruce's book "Lighter, Faster, Simpler, Better Java" knows that he is not stupid and he has the credibility to discuss about this topic. Although I do not agree with all his hype about Ruby and RoR, I think everybody should listen what he has to say about this. RoR is growing very fast and you should not underestimate its power. You should at least understand what people don't like about Struts, XML and other frameworks full of power that no-one knows how to use it.

    Again: Programatic Configuration, CoC, Abstraction of the real web problems is the key to Java's salvation in the web development world.

    I really suggest that everybody give it a try to Mentawai to understand what I am saying. (http://www.mentaframework.org/)
  268. It is not Java's fault ![ Go to top ]

    I have read Lighter, Faster, Better, Simpler Java from the same author and I love his attitude toward the wrong things people have done with the Java language. In the top of this list, Struts and EJB holds a very strong position of the worst of the worst in the Java world. But that's not Java's fault. If people want to do things very, very complicated like EJB or very, very boring like Struts with Java, they will keep on doing it. Either with Java, Ruby or anything else. Any OO language can abstract the complexity of the most common and repetitive tasks of any web project, but as always people tend to focus on power and forget about simplicity or KISS (keep it simple stupid). Before you think Java is not suitable for web applications, I suggest you try Mentawai or Rife. I believe Ruby and Rails is the next big thing for very simple and small projects. There is no way you can compare Active Record with Hibernate or how you can use page conventions for a big project. Beyond passion there is rationality. I am still in love for Java, but the passion days are over.So before you jump to RoR because you are tired of Struts, XML, WW, Spring, etc, take a look in a much simpler, pragmatic, joyful solution to web development. PROGRAMATIC CONFIGURATION IS THE SALVATION !!!http://www.mentaframework.org/

    I don't agree with that. Explain.
  269. Java: Dead Like COBOL, Not Like Elvis?[ Go to top ]

    If you ever make it to Austin, look me up for a beer. You might be surprised on how much we agree.

    Hi Bruce,

    thank you for your clement reply to my post, which, after reading it again this morning, I judge to be quite inflammatory myself. Sorry for my harsh words -- thanks again for your leniency towards me.

    Your points are well taken, in particular the third one: I already noticed that on TSS, more and more provocative opinionated editorials are posted, possibly to generate more traffic on this site. Especially the claim that Ruby (on Rails) could kill Java crops up ever so often. How problematic that sort of attention grabbing is can be seen when people who actually are well aware of this fact cannot refrain from joining the discussion with a sort of knee-jerk reaction. Mea culpa! Actually, I guess it is the topic that unnerves me, and the way TSS continues to spread FUD about it (as if there could be only one true way to develop server side applications -- quite religious, I'd say).

    Oh, and if you ever happen to find yourself in the town of Lüneburg, Germany, ... :-)

    Cheers,
    Lars
  270. Remember people were so scare when we said the world is round before..
  271. Remember people were so scare when we said the world is round before..

    The "flat earth" myth is a modern invention.

    http://www.google.com/search?q=the+world+is+flat+myth&start=0&ie=utf-8&oe=utf-8&client=firefox-a&rls=org.mozilla:en-US:official

    In the middle ages, it was commonly accepted that the world was spherical. Even the Egyptians (thousands of years ago!) new that it was a sphere and had even calculated its size.

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  272. Java: Dead Like COBOL, Not Like Elvis?[ Go to top ]

    Even the Egyptians (thousands of years ago!) new that it was a sphere and had even calculated its size

    The Hebrews (Jews) knew it thousands of years ago too. :)
  273. Java: not dead, but ugly indeed[ Go to top ]

    Greetings,

    Bruce's comment of Java being "dead likce COBOL, not like Elvis" is asinine. The sheer amount of new developments in this area shows that a lot of people continue to work on it at a pace not seen before in any programming language. Statements like that are as bad as those from the Java fanboys, from the casual hobbyist who just discovered the language to the JCP members who try to cover the sun with their thumb and pretend that there are no problems in Java land.

    Ruby on Rails and a cartload of other languages and platforms are evolving. The key, for Bruce and anyone else, is to figure out what the problem at hand is and to apply the best tool that solves the problem. Engaging in sophomoric name-calling (MyLanguage is better than your language!) is stupid. These things have an application domain. Java isn't the best solution for all cases, nor is Ruby or .Net. Why do all these talking heads want to pose these issues as "MyLanguage is killing X" all the time? Java was supposed to kill C++... and both have healthy mindshare percentages. For something "dead", Java has the largest number of developers of any modern programming language.

    Now if we look at reasons for why Java is screwed, they are a combination of two big factors: the Java programmers' assumption that everything they'll need is in the API packages and the JCP's reluctance to evolve the platform in significant ways.

    Java programming and frameworks for the web let even mediocre programmers be successful. That creates a mind set of complacency among developers who become too lazy to analyze and implement clean solutions and rely too heavily on the frameworks. These people should learn that the Java API doesn't always have the best answer. The indiscriminate use of the Java API in all its forms can create a myriad of performance and scalibility problems that most of these coders can't even comprehend. Most of these "API jockeys" who claim to be aces at Java programming can't solve the simplest problems when moving from, say, the Java web development platforms to J2ME or OSGi. A missing API paralyzes them because at that point it becomes obvious that they don't know what they're doing and can't implement the things they need themselves.

    The other problem is the JCP. The process is slow and too protective of the interests of its members. They are too afraid to make significant changes to the Java platform. Many of the JSRs are purposedly incomplete so that a Java solution won't solve all issues in a problem domain, stepping on third-party vendors' proprietary technology. The billions of dollars invested in the JCP are a two-edged sword: they are advancing, albeit at a snail's pace, the Java technologies they review; on the other hand, the process seems to stall or shape the JSRs in unhealthy directions when one of the proposed technologies threatens one or more of the members' markets.

    So, is Java dead like Elvis or COBOL? Neither. Java technologies are thriving. I'd say that Bruce was just trolling on that one. The real question is, is Java elegant enough and evolving in healthy ways to NOT die? The answer is "no". The hubris shown by the people who have vested interests in Java is blinding them to this; they're becoming complacent. There are many other technologies that *could* overtake Java programming/platforms and that are evolving at a more rapid pace.

    Nothing would make me happier than seeing Java evolve at a quick pace and maintain its leading position... I just don't see it happening.

    Cheers,

    E
  274. "Enterprise"????[ Go to top ]

    Every programmer I know jokes about how pathetic EJB's were and how they will never touch them again with a ten foot pole. On the other hand they love Java and feel very productive these days. Mainly they feel productive because they use a lot of open source frameworks, and relatively few "Enterprise" frameworks -- they've utterly ditched anything EJB related. The whole term, "Enterprise", has taken on a taint because it was hijacked by companies trying to foist crappy product on top of even worse specs. The artificial distinction created by sun around "Enterprise" Java has really created a backlash in the Java community."Enterprise Java"?? C'mon! The emperor has no clothes.
  275. Yes, surely "Enterprise"[ Go to top ]

    Every programmer I know jokes about how pathetic EJB's were and how they will never touch them again with a ten foot pole. On the other hand they love Java and feel very productive these days. Mainly they feel productive because they use a lot of open source frameworks, and relatively few "Enterprise" frameworks -- they've utterly ditched anything EJB related. The whole term, "Enterprise", has taken on a taint because it was hijacked by companies trying to foist crappy product on top of even worse specs. The artificial distinction created by sun around "Enterprise" Java has really created a backlash in the Java community."Enterprise Java"?? C'mon! The emperor has no clothes.

    Geoff, I totally disagree with you.

    Actually, no matter how tough it was to master EJBs, they solved many important issues on enterprise solutions, specially when it comes to distibuted container-managed transactions.

    Most people who complain about them are the same dumb-arses who think it is pretty normal to call "cn.setAutoCommit(true)" on a connection obtained from a JNDI datasource. These morons could never quite understand why their code always fail, and some are even stupid enough to give up on datasources and use direct JDBC instead.

    Even with all of their issues, EJBs are by far the best thing on J2EE until now (even entity beans are cool if you use a nice container). Reuse on enterprise environments is only possible with EJBs and their container-managed transaction isolation. But reuse can only be achieved by mature developments teams (not by body-shop teams hired-by-hour who are rewarded for beeing innefective).
  276. So Bruce couldn't do it in 4 months with Java and could do it in 4 days with RubyOnRails? That would be a productivity increase of more than 30x. Even the biggest RubyOnRails fanboy would admit that this number is much too high. But what does this tell about Bruce? Maybe he is not the best Java programmer and Ruby is just right for him or that he is doing the best to sell his (upcoming) RubyOnRails book...

    Maybe ROR makes the developers happy, but does it make the customers happy given bidding schemes like the following (http://www.relevancellc.com/blogs/?p=92) and the result being a webapp in one of the slowest interpreted languages with almost no developers for maintenance (ever heard of lock-in)?

    quote from above url: "
    * For applications in the Rails sweet spot (CRUD+Ajax on the web) our Rails price tends to be 30-50% less than the same bid implemented in Java.
    * For applications that are nowhere near the Rails sweet spot (do you know what these are?), our Rails price tends to be only 10% less than the same project implemented in Java
    * Applications are completed twice as quickly in Rails.
    * When customers want an hourly rate, our hourly rate for Rails work is slightly more than our hourly rate for Java work. However, given that applications are finished 30-50% faster, Ruby/Rails still delivers more per dollar.
    "
  277. I'm definitely not the best programmer, but let me clarify this statement again. (This is the third time around on tss.) The second time around, you're definitely going to be faster. A lot faster. You know the data model better, and the web flow better. But the difference was great enough for us to take notice. Primarily, we were a perfect rails app. We existed to cram data into a sophisticated schema. ActiveRecord is very lazy; for our app, that was ok. Our user interface was simple. We had very little business logic. In this case, the problem fit ActiveRecord better than it fit Hibernate. (I'd bet that for projects in general, they would fit Active Record more often than Java guys would admit, but less frequently than the Rails guys would admit.)

    I'd estimate that if I stay squarely in the Rails sweet spot, I code from 5-10x faster. If I have to bend the framework around the schema, it's probably about 3-5x. If I have to do significant AJAX or if the model is easy to bend to Active Record, the numbers go up. The lack of refactoring support costs me some, but I make it back up by having rake and the interactive consoles.

    Now, that's just the coding time. If you spend most of your days in meetings, you're not going to notice much of a difference. But if you can spend most of your time coding (most projects don't), it's significant.

    I'm going to drop off of this thread for a while. I've got to go get some work done...but I hope I've clarified the statements in the interview. I don't think Java's dead; I do think it's in danger of losing its market dominance and leadership.
  278. How to quantify 4 Months vs 4 Days[ Go to top ]

    Would Bruce be willing to publish the Java code that took 4 months to write and the Ruby code that took 4 days? One thing that I know is that once I solve a puzzle, the second solving takes much less time. I look at some code that I wrote 5 years ago and I am aghast at the inefficiencies.

    John Murray
    Sobetech
  279. Java: Dead Like COBOL, Not Like Elvis?[ Go to top ]

    In an interview with idevnews.com, author Bruce Tate says Java/J2EE is facing dramatic change, and could be "dead like COBOL, not like Elvis."

    I didn't see Bruce Tate saying "dead like COBOL, not like Elvis". That is what the interviewer said.
    Tell you what Brucey, if you think java is so dead, why don't you leave javaland forever, and stop annoying us with your pathetic attempts at selling more of your tawdry, tedious, and terminally boring books?

    Who wants to place bets on more people wanting bileboy to leave "javaland" than Bruce Tate?

    But on to the meat of the issue. Java has a problem (that .NET doesn't), in that Java is a language, a virtual machine, and a set of APIs/libraries/specifications at the same time.

    Java, the language, has issues. There's too much boilerplate which means it's not very readable. Yes, I said it. Too much boilerplate makes a language not very readable - unlike what a bunch of morons have been spewing for god knows how many years about Java. The only thing good is that you got your IDEs to spew out a bunch of crap.

    Ruby is probably not "the answer". There are too many people that will resist dynamic typing, but there are languages now and nothing stopping Sun from incorporating many of the ideas of a dynamic language into another statically-typed language that plays nicely with the JVM and the libraries via type inferencing, a macro system, and other stuff.

    Gosling just said in an interview http://www.gotw.ca/publications/c_family_interview.htm that he wishes he would have put in multiple return values. And you don't have pass by reference in Java so you end up with a bunch of little stupid classes to do simple stuff.

    The good things about Java are the IDEs, tons of open source and free code, lots of industry support, jobs...

    But it's not too early for Sun to start thinking and even implementing something on top of the JVM (is it too late for Dolphin?). Don't wait for Java to become as old as Fortran to do the Fortress of Java.
  280. Java: Dead Like COBOL, Not Like Elvis?[ Go to top ]

    Hi Frank,
    But it's not too early for Sun to start thinking and even implementing something on top of the JVM (is it too late for Dolphin?). Don't wait for Java to become as old as Fortran to do the Fortress of Java.

    Aren't they doing that with Mustang's support for scripting languages (JSR 223)? I haven't looked into it too deeply, but my understanding is that they're providing enough hooks that you can put JavaScript, Python, or pretty much anything on top of Java.

    Or are you advocating something else?
  281. Java: Dead Like COBOL, Not Like Elvis?[ Go to top ]

    Aren't they doing that with Mustang's support for scripting languages (JSR 223)? I haven't looked into it too deeply, but my understanding is that they're providing enough hooks that you can put JavaScript, Python, or pretty much anything on top of Java.

    Or are you advocating something else?

    IIRC, the bytecode instruction that will make it easier for dynamic language implementations on the JVM is going into Dolphin.

    But Python, Ruby, Javascript are probably not what most Java developers want. Dynamically typed languages have "issues" when playing with IDEs and possibly some performance considerations. It's probably possible to get 90% of the dynamic languages agility in a statically-typed language. And it would seem that PHBs need some kind of "officialdom" from Sun and/or IBM. Looking at something like Boo that was built specifically for .NET would seems to be a starting point.

    Groovy seems to have issues.
  282. A big part of what can make things like RoR work is the runtime magic enabled by languages like Ruby and Python.

    The thing is compilers can work magic, too. The problem is C++ compiler magic made people think that all compiler magic is evil.

    I think what's needed is a new language that learns from many existing languages, from C++ to Java to Python and Ruby and is compiled to the JVM (and the CLR ;-). It needs to be cleanly compatible with any library written in Java (or C# for the CLR).

    Someone just has to take the time to really study what about each language makes it great, rather than just declaring the language great. People would rather enter religous language wars.
  283. Java: Dead Like COBOL, Not Like Elvis?[ Go to top ]

    I think, developers want a new language/platform every 10 years or so, which stimulates them intellectually. Java, while rich, is showing its age and those who get bored by the mundane idiosyncrasies of the language look for alternatives. 10+ years ago, C++ developers (including me :-( ) used to feel this way when someone says, "Java is the way to go." I don't mean to say that RoR is better than Java or the future, but it is at least "different." Spring framework convinced us that there is a simpler, lighter way to develop enterprise apps. Hibernate convinced us that there is a better alternative to entity beans. These and similar open source frameworks have so much influance on Java platform that EJB3 incorporated many of these notions. In other words, innovations are happening outside the scope of JSRs and standards. And slowly, those innovations look beyond the scope of Java. Whether we like it or not, sooner or later, there will be a new language/platform that we need to learn, in order to earn a living.

    Bruce's comments may have some faults and RoR may or may not be the future, but I will commend him for his courage to speak his mind. It is dangerous to believe that Java is everything and nothing can be better than that.

    Peace.
  284. Java: Dead Like COBOL, Not Like Elvis?[ Go to top ]

    Who wants to place bets on more people wanting bileboy to leave "javaland" than Bruce Tate?

    Silly question, Frank. If "javaland" is big enough for Mark Fleury's ego, it's big enough for a couple hundred Hanis and Bruces.
    Java has a problem (that .NET doesn't), in that Java is a language, a virtual machine, and a set of APIs/libraries/specifications at the same time.

    Last time I checked, .NET was just a non-compliant implementation of Java that is bundled with Windows.
    Java, the language, has issues.

    Java has lots of issues. It includes lots of crap in the language and the libraries. The Sun JVM has more cut-and-paste crap than your average COBOL program.

    Yet it works and it is the engine that has driven the high-end software industry and computer science academia for the past ten years.

    Bruce is not stupid, and Ruby/RoR is not idiotic. "Javaland" as you called it is plenty big enough to adopt or at least work with them all. (When's jRuby going to be done?)

    My personal favorite thing about "javaland" is that we don't all have to agree or do it "the one true way". That's the bulls*** that we got rid of by moving out of the paternalistic and predatory Microsoft shadow.

    Yeah, Java is a mess. So is life, and I'm enjoying both of them ;-)

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  285. Java: Dead Like COBOL, Not Like Elvis?[ Go to top ]

    Last time I checked, .NET was just a non-compliant implementation of Java that is bundled with Windows.

    Last time you checked? With stupid statements like, we can only assume that you've never checked.
  286. Java: Dead Like COBOL, Not Like Elvis?[ Go to top ]

    Last time I checked, .NET was just a non-compliant implementation of Java that is bundled with Windows.

    Last time you checked? With stupid statements like, we can only assume that you've never checked.

    You're missing your sense of humor today, Mr. Frank Bank.

    As for .NET, I spent quite a bit of time with it since long before it was called .NET, and I still work with it today. It was Microsoft's "clean room" Java implementation, and then when they couldn't legally screw up Java, they had to rename it.

    Any way you slice it, it's just a non-compliant JVM .. ;-)

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  287. Perhaps if you do a silly walk when you say it, it will be more obvious the post is meant to be humorous. Better yet, go to the ministry of silly walks and master of of their gems. Then those who are humor impaired won't be able to help but laugh.

    peter
  288. Java: Dead Like COBOL, Not Like Elvis?[ Go to top ]

    You're missing your sense of humor today, Mr. Frank Bank.

    Humor or bitterness? It's hard to tell when so many "java programmers" are circling the wagons when the R word comes up.
    Any way you slice it, it's just a non-compliant JVM .. ;-)

    Kindof like how Java is a non-compliant, dumbed-down, p-coded C++.
  289. Java: Dead Like COBOL, Not Like Elvis?[ Go to top ]

    Silly question, Frank. If "javaland" is big enough for Mark Fleury's ego, it's big enough for a couple hundred Hanis and Bruces.

    Bileboy wanted Bruce Tate to leave Javaland.
    Yet it works and it is the engine that has driven the high-end software industry and computer science academia for the past ten years.

    10 years ago, Java was a stupid little language for writing applets and not driving the high-end software industry and computer science academia
    Bruce is not stupid, and Ruby/RoR is not idiotic. "Javaland" as you called it is plenty big enough to adopt or at least work with them all. (When's jRuby going to be done?)

    Bileboy called it "javaland".
    That's the bulls*** that we got rid of by moving out of the paternalistic and predatory Microsoft shadow.

    "Paternalistic and predatory Microsoft shadow", huh? You pick that up over at Slashdweeb? Nice one.
  290. Java: Dead Like COBOL, Not Like Elvis?[ Go to top ]

    Yet it works and it is the engine that has driven the high-end software industry and computer science academia for the past ten years.

    10 years ago, Java was a stupid little language for writing applets and not driving the high-end software industry and computer science academia

    Ten years ago I was building incremental compilers and early AOP tools in Java, and Java was already quite a rage at MIT.
    That's the bulls*** that we got rid of by moving out of the paternalistic and predatory Microsoft shadow.

    "Paternalistic and predatory Microsoft shadow", huh? You pick that up over at Slashdweeb? Nice one.

    Frank, you need some insult training from Hani.

    And if you need to know anything about programming Windows, just ask. I'm a Microsoft MVP :-)

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  291. Java: Dead Like COBOL, Not Like Elvis?[ Go to top ]

    ...and Java was already quite a rage at MIT.

    Now that's funny
    Frank, you need some insult training from Hani.

    Oh, I used up all my good biles on the latest Hani interview thread. But thanks for informing me on how scary Microsoft really is. I sure don't want to be caught in that "predatory Microsoft shadow"
    And if you need to know anything about programming Windows, just ask. I'm a Microsoft MVP :-)

    No, that's ok. I've been scared off by Microsoft's predatory shadow.
  292. Remember when Smalltalk was going to take over the world?
    Clipper? VB?

    I’m still waiting.

    The true strength of Java is it adapts to changing conditions. Ten years from now, it will still be called Java, but it may be unrecognizable compared to today.
  293. Rails has a long way to come...[ Go to top ]

    ... but, they are moving fast, and in the right direction.
    There are simple and standard solutions to common problems in Rails and in Ruby, where as I've found Java to have complex and non-standard approaches to the same problems.

    I love the fact that Rails isn't owned by someone like Sun.

    It's OSS, it has an amazing community, and it's headed in the right direction. It's also extremely intuitive, fast to develop in, and ... it's fun.
  294. And another thing![ Go to top ]

    How is any of this really news?

    Didn't we cover this topic at length just recently?

    This conversation comes to mind:

    http://www.theserverside.com/news/thread.tss?thread_id=37121
  295. Echoes and echoes and echoes[ Go to top ]

    I just keep hearing echoes. From ten years ago, when Java didn't have any way to talk to databases. Period. No JDBC, EJB, JDO, or Hibernate.

    Echoes of the defensiveness and anger that I heard from the C++ developers about this stupid little toy language that couldn't do anything more important than bouncing heads in a web page.

    Remember when JTA didn't exist?

    Remember when Servlets didn't exist?

    How about JSP or JAXB?

    Java didn't spring full-formed ready to integrate the world. It got there over time, gaining attention through a fair amount of marketing (and yes, hype) and some very real productivity gains.

    All Bruce started off saying, in the book and in interviews, was this: There are things to be learned, inspiration to be gained, from some of these other interesting places. The Java community can learn from these and the language many of us love can grow and adapt. Individual programmers can learn from these and become better programmers. Or, you can choose to disregard them and risk getting blindsided later.

    I wasn't always a Java programmer. Java got brought to my attention by a colleague that seemed kind of daft at the time. But I took a look, and I liked what I saw.

    Now, I'm taking a look at continuation servers, and I like what I see.

    This hostile dynamic has polarized reactions to such an astonishing degree that conversation seems to be nearly impossible. One can only conclude that people feel personally threatened and offended by Bruce's book. But, he didn't create Ruby on Rails, continuation servers, or scripting languages.
  296. Echoes and echoes and echoes[ Go to top ]

    To me Bruce Tate comes across as an opportunist looking for book writing opportunties. If you look at the name of the books he wrote, "Bitter Java this" "Bitter Java that" and also thing s like Java visionaries are moving away etc. anything but constructive. But he is ultra sensitive to criticism

    My visionaries in Java community are people like Gosling, Joshua Bloch, Gavin King, Rod Johnson. As a Java developer for a while, I do not have any time for people like Bruce. I only think good riddance.

    I do not think Ruby programmers are on programming high ground. There is only leech mentality and hitch a ride on Java's popularity. Many of the posts by Ruby crowd in this forum, are doing only disservice to their cause.

    If I want any need for Ruby programming, I will go to the relevant forum. Aggressive hype by Ruby fanatics only turns people away from it.
  297. Echoes and echoes and echoes[ Go to top ]

    To me Bruce Tate comes across as an opportunist looking for book writing opportunties.
    Actually, it's one of the few areas where I believe Bruce when he says that he's not making that much money off his books. And any author of a technical book can probably agree.

    What does matter, though, is that he's a consultant. The upside of being a consultant is that you don't have to care about standards. The bad news is that your clients have a strong say in the technologies that you have to use.

    Ruby on Rails is a tough sell everywhere outside geekland, and I suppose that one way of fixing this is to go public and claim that it's the next big thing, and then point your clients to sensational headlines and interviews with Ruby-friendly Web sites in an attempt to warm them to Ruby.

    I can't blame Bruce for trying...

    --
    Cedric
  298. Ruby isn't such a hard sell?[ Go to top ]

    Cedric,

    We have found that for the right projects, Rails has been an easy sell.

    There is a difference between selling to a huge company that thinks it is needs "enterprise software" and small companies that just need applications that save them money.

    Cheers,

    Dion
    Ajaxian.com
  299. Ruby isn't such a hard sell?[ Go to top ]

    There is a difference between selling to a huge company that thinks it is needs "enterprise software" and small companies that just need applications that save them money.

    And oddly, they still buy Microsoft.
  300. Ruby isn't such a hard sell?[ Go to top ]

    Cedric,We have found that for the right projects, Rails has been an easy sell. There is a difference between selling to a huge company that thinks it is needs "enterprise software" and small companies that just need applications that save them money.Cheers,DionAjaxian.com

    We sold a 3 page app, done quickly to a customer based on Spring, Struts, and Hibernate. Guess how much the software cost?
  301. Echoes and echoes and echoes[ Go to top ]

    I do not think Ruby programmers are on programming high ground. There is only leech mentality and hitch a ride on Java's popularity. Many of the posts by Ruby crowd in this forum, are doing only disservice to their cause.

    If I want any need for Ruby programming, I will go to the relevant forum. Aggressive hype by Ruby fanatics only turns people away from it.

    Haha, you mean like the TSS editor that posted this? Do you ever stop and think why Ruby,RoR, "death of java" stories come up about every week or so? Here's the cluestick. It's so people like you make the post you just did. Hook...line...sinker.
  302. Echoes and echoes and echoes[ Go to top ]

    My visionaries in Java community are people like Gosling, Joshua Bloch, Gavin King, Rod Johnson.

    Agreed. They are visionaries within the Java community. Are there also visionaries outside the community that might have interesting things to say? I think so. A couple of hours spent on lambda-the-ultimate should convince anyone that there is deep thought coming from outside the Java community.

    Notice that I was not making a "Java is dead" remark or a "RoR is the only way to go". I don't think either of those statements are helpful. Presenting your position as a direct threat to someone else's livelihood (or identity!) rarely leads to intelligent discussion.

    My entire point was that looking inward is a sure way to get blindsided by some external force majeure. A community that adopts such a defensive posture, that activates the antibodies at a perceived threat (OK, sometimes explicitly stated threat!), is not adapting. The essence of responding to a threat is adaptation. Circling the wagons just leads to a massacre.

    B B, I can understand your personal aversion to self-promotion and hype-mongering. But, even offensive jerks can sometimes have useful things to say. Surely that's part of why the BileBlog is popular, right? If it were just Hani spewing filth, no-one would read. (Well for more than a day or two.) It's that he usually has a nugget or two of truth in his posts that make it worth reading.

    Too much of what I hear here on TSS sounds like "la la la I'm not listening".

    Case in point, have you looked at the continuation server model for web programming? It's quite radically different than the request-response model embodied by servlets & JSP. In many ways, continuation servers are more "object-friendly" than other web programming models. That's an interesting tool in my toolbox now, that I didn't have before reading "Beyond Java".

    Maybe I'm wrong, and maybe the hostile response here doesn't fully reflect people reactions. Maybe posters are also reading sources outside of the Java community. I hope so.
  303. The smell of a flame war[ Go to top ]

    I have to say it's rather fun to read the flame war. 30 years from now, all of it won't really amount to anything. things move in cycles. A philosopher once said, "the only constant is change."

    anyone making a good living as a programmer doesn't have to worry or be afraid. Change will happen and those with the skills will adapt. Whether Java takes ideas from Ruby, or Ruby knocks out Java and C# is anyone's guess.

    peter
  304. A complex datamodel...[ Go to top ]

    I was working on a project to build a web front end onto a backend with a complex data model. In Java, it was just taking too long.
    ...
    Bruce then goes on to say that he modeled the database in two days with Ruby on Rails
    ...
    I just picked out those two statements that seem to be quite contradictory to me. This goes like (a) "there is a datamodel" and then Mr. Tate is (b) "modelling the database". Huh? Am I missing something? If you connect to a backend system in order to create a web frontend, you do not model the database. You connect to it. You use it. There are about a dozen tools in any given language for how to something like that more or less effectively. Even when writing the code with java SE on board tools only (Plain JDBC) without any additional libraries, such a project will not take more than one or two months, and when it does, any decent developer will start thinking about writing a tool that does the job (or spend a couple of days researching the market). The advantage with RoR is that there is nothing to research. You decide, you use it, it will work, as will the dozen or so tools you get in most other languages.
  305. I found this thread quite interesting. Specially the proposals of "opensource Java", which makes me wonder if people really think about the future instead of "following the hype" mindlessly.

    Java needs unity, and that's what JCP is for. Adding certain things to the platform/language has lots of implications and making it opensource won't remove the "implications" of changes.

    The day Java loses its unity it's going to be day Microsoft will take over. JAVA WOULD HAVE THE SAME FATE AS UNIX.

    The GREAT advantage of .Net is that it's one platform from one vendor, that makes everything easier. Java has lots of vendors, but its standards are enforced. So it makes things not as good as one vendor, but still good.

    Now opensource... Linux is the perfect example of the big mess it is, 751 different distributions, each with it's own philosophy, incompatible, for you "to choose from". Lots of unfinished, unmaintained, buggy software.

    I believe opensource has its place, there are lots of excellent softwares around (they are minority), but taking something that it's perfectly good and braking it into pieces, despite of what history show us, it's BEYOND LOGIC.

    That should next Bruce Tate's book title "Beyond Logic". Since all Ruby hype is around "Happiness", I think it suits them very well, :)

    PS.: Java is not perfect, but it still has a long way to go. It's going to evolve with time, the way it has done so far. Saying it has reached the "peak" it's just BEYOND LOGIC.
  306. Lack of maturity[ Go to top ]

    I wish I could move some Java web applications to Ruby and Rails, for productivity reasons for small to medium applications but Ruby as a platform is not mature enough:

    a) Ruby doesn't support unicode (well the String class) which is really annoying and workarounds require modifying existing code (extending String class) or break lower level API (overriding String class).
    b) ReXML is nice but lacks XML validation on XML schema or DTD.
    c) Ruby is slow.
    d) IRB ruby interactive interpreter doesn't support non-english keyboards (I can't type [ character for instance on my french keyboard)(I'd rather avoid learning ASCII codes for these characters)

    Ok point d) is not that an issue but the other ones are really a "no go" for me. And see also deployment issues for production environments (mentioned in this thread) where mod_ruby for Apache is not supported any more and FastCGI/lighttpd not stable enough. I restrict today my Ruby usage to small CLI tools. I hope we'll see improvements in the areas that I mentioned above shortly (Ruby 2.0 on a new VM or JRuby being fully compliant with ruby 1.8.4).
  307. Java: Dead Like COBOL, Not Like Elvis?[ Go to top ]

    Reading and even posting reply is waste of time for this article :)
  308. InvalidArgumentException[ Go to top ]

    Nuff said, join the real world, java is everywhere.
  309. Learn from RoR[ Go to top ]

    First of all, I don´t get why a lot of people (including Bruce) compare Java with RoR.

    Ask yourself: Is RoR hot because of Ruby ? Or is RoR hot, because it offers a lot of default behaviour ?

    We would have a much more interestings discusion, if we would compare RoR with Tapetry / WebWork / ...
  310. Java and Ruby can live together[ Go to top ]

    First of all: I don't think Java is dead.

    However, I think Bruce Tate used this loaded statement to draw some attention. Also, you must admit the man has a point!

    I think the problem with Java is, that it is wrongly used in 50% of all cases (maybe even more).
    There is no need to create a full blown J2EE web application if your goal is to create a simple weblog. You don't need distributed transactions, distributed cache, etc...
    J2EE in general is complex and complicated, because it tries to solve some extremely hard to solve issues.
    Bruce Tate was one of the first people to wake up the Java community about this, so give him some credit for this.

    Ruby (and Rails) allows people to create simple full blown database driven Web applications in lightning fast development time.

    Of course, you can't use RoR to create a banking application serving millions of requests a day, over several distributed systems. J2EE will be much more appropriate here.

    However, you could use Ruby in a structered object oriented matter, to create a simple content management system, a weblog, simple business applications, etc....

    What is wrong with that? Why can't Java and Ruby co-exists?

    Why instead of fighting about it, why can't combine our efforts and try to run Ruby on Rails on the JVM and enjoy the best of both worlds?
  311. Java and Ruby can live together[ Go to top ]

    I think the problem with Java is, that it is wrongly used in 50% of all cases (maybe even more).
    Used in the wrong way? or Should not have been used?

    I definitely agree with the first statement. Things are changing though.
  312. Java and Ruby can live together[ Go to top ]

    First of all: I don't think Java is dead. However, I think Bruce Tate used this loaded statement to draw some attention. Also, you must admit the man has a point!I think the problem with Java is, that it is wrongly used in 50% of all cases (maybe even more). There is no need to create a full blown J2EE web application if your goal is to create a simple weblog. You don't need distributed transactions, distributed cache, etc...J2EE in general is complex and complicated, because it tries to solve some extremely hard to solve issues.Bruce Tate was one of the first people to wake up the Java community about this, so give him some credit for this.Ruby (and Rails) allows people to create simple full blown database driven Web applications in lightning fast development time.Of course, you can't use RoR to create a banking application serving millions of requests a day, over several distributed systems. J2EE will be much more appropriate here. However, you could use Ruby in a structered object oriented matter, to create a simple content management system, a weblog, simple business applications, etc....What is wrong with that? Why can't Java and Ruby co-exists?Why instead of fighting about it, why can't combine our efforts and try to run Ruby on Rails on the JVM and enjoy the best of both worlds?

    Here's the problem. I wouldn't want to fracture my development this way. I'd rather use the same basic approach, if possible, for applications small and large.

    Where I work, I'm likely to work on several projects per year, a mixture of new development and enhancments to projects done the previous year. Our project sizes range from small to medium sized, web-applications.

    Imaging having to shift from a ROR app to Java app, each specific application with different code and approaches. Our apps have standardized on Struts, Spring, and Hibernate and scales down to even two page applications very well. Yet, it has the same basic configuration and architecture as its big brothers.

    ROR so-called faster development has no advantages. If you work on our smaller apps, you will understand the longer ones. If you haven't worked on an app in 6 months, but a customer request comes in for enhancements, you are not spending time ramping up or ROR. We had a project sit on the shelf for a year then BAM! The customer was suddenly ready to roll.

    This common approach allows me to reuse and prototype within all the projects to such a degree that we have a slew of features ready out of the box. Even our small apps get transactional support, security, caching, profiling, and recently Quartz-based scheduling right out the box.

    I'm currently ramping up on JSF and the same benefits kick in again.
    I'd rather select a technology that scales up and down than support several because they are lacking in some context.
  313. When I look at Ruby, it looks like a decent language. But the question is, is it really significantly easier than Java?

    The basics are like in Java but with lots of short cuts to do things added. In fact, there are so many shortcuts that it might take a good while before you can properly read the code written by a Ruby geek. Reading is easier than writing, so it would take even longer to master all the little things that you can use to make your code more compact.

    Apart from that, there is Ruby on Rails. It is a framework written in Ruby, but does Ruby make Rails much better than Java would? Take Rails away from Ruby, and what's left? I know a lot of Ruby geeks would jump out of the framework to declare all the great things done in Ruby, but honestly, there would not be much of a fuss without Rails. All glory to Rails but it can be copied to Java and other languages without too much work. Where does it leave Ruby?
  314. Anti-marketing marketing[ Go to top ]

    The formula: If one wants to sell books/conferences/seminars, one has to be controversial. No need to jump up 'n down and to get upset. Let the man sell his stuff in peace :).
  315. The entire theatrics (a la Shakespeare) that is going on in this thread can be put at bay for a while, I hope. IMHO, we are on the verge of emergence of a new (no pun intended!) programming paradigm. However, as everyone else will agree, that will happen only if it makes sense. Now, as I was going through the rigor of OOP and its promises, it seems likely that it has already lived down its purposes. With the advent of new processing technology we require languages that will be able to exploit these features more efficiently. With the functional programming languages, if they can live up to their promises, we can certainly look forward to that future where Java is defunct.

    -Abhijit
  316. Everyone knows it not possible to develop anything beyond the absolute trivial in just four days.

    So what did they do to take four months to try to implement something trivial?

    And do not think that anyone will be able to convince me that any kind of supertool suddenly cuts the development time to 1/30.

    Bruce! Bow your head in shame for lying to us.
  317. Don´t blame - learn ![ Go to top ]

    In my opinion, instead of blaming and instructing each other, we should try to understand what Mr. Tate and his fellows are trying to say.

    First of all, we should recognise that programming in a dynamic language such as Ruby is (!) faster. You simply have a higher level of abstraction, which allows you to express statements in a more compact format. Im especially thrilled of dynamic typing and the perfect integration of regular expressions.

    I know that this is beeing told 100x times but the Step from Java -> Ruby is comparable to C++ -> Java. Recently I worked for on a C++ project...and I can tell you, that I didnt enjoy it. Also the difference to Java is not enormous, so I programmed in C++ like in Java, beeing OOP and practising agile methodologies. Have you ever written testclasses in C++ ? it´s no fun. You do the same, but much more messy than in Java.

    What I´m trying to say is that the advantage of a language like Ruby will ONLY be recognised if you give it a try and work with it.

    Just as C++ (C++ is second @ Sourceforge), Java will alway be very active.

    Why would someone program still with C++ today ?
    1) Because of requirements, in examp. accessing Hardware Resources.

    Why would someone program with Java today ?
    1) Because he didnt give Ruby a try
    2) Because it meets his requirements = EE

    In my opinion 1) will diassapear sometime in the future and Java will remain (still) as an excellent choice on our programming-belt for suatable tasks.

    cheers,
    Andreas
  318. Don´t blame - learn ![ Go to top ]

    +1 Good post. Balanced and informed.
  319. Don´t blame - learn ![ Go to top ]

    ..., we should recognise that programming in a dynamic language such as Ruby is (!) faster....

    It's faster until you change an interface and then try to find what you might have broken - in the haystack
  320. Is Ruby faster to develop?[ Go to top ]

    ..., we should recognise that programming in a dynamic language such as Ruby is (!) faster....
    It's faster until you change an interface and then try to find what you might have broken - in the haystack

    I do not agree with this argument. As a matter of fact, Java is statically typed, but this is most of the time bypassed by implicitely casting to Object when storing stuff in collections and by explicitely casting to whatever is required when taking stuff out of collections.

    So as a matter of fact Java is also heavily relying on a runtime mechanism for ensuring the typing rules are kept. Not so different from Ruby.

    Automatic tests and maybe debugging can help with this.
  321. Is Ruby faster to develop?[ Go to top ]

    As a matter of fact, Java is statically typed, but this is most of the time bypassed by implicitely casting to Object when storing stuff in collections and by explicitely casting to whatever is required when taking stuff out of collections.So as a matter of fact Java is also heavily relying on a runtime mechanism for ensuring the typing rules are kept. Not so different from Ruby.

    Not if you use generics.
  322. Is Ruby faster to develop?[ Go to top ]

    The issue of adding the typesafety that Java claims to have, but did not have by generics is a long story. From what I have heard about it, it is at least questionable that generics really address this issue for good. They create a lot of problems themselves. I would just live with the lack of so called "type-safety" and leave it to the dynamic part of the language to do the type checking. I consider that approach superior anyway.
  323. Is Ruby faster to develop?[ Go to top ]

    The issue of adding the typesafety that Java claims to have, but did not have by generics is a long story. From what I have heard about it, it is at least questionable that generics really address this issue for good. They create a lot of problems themselves. I would just live with the lack of so called "type-safety" and leave it to the dynamic part of the language to do the type checking. I consider that approach superior anyway.
    I totally agree. I've been reading through the responses to my original post, and their seems to be this elusion out there that a static compile time type test some how protects you from interface changes. It doesn't. In Java remote services are delivered through the Java Interface - which is a restricted form of dynamic binding anyway. If the service interface changes then you will get a runtime exception just as you would with a dynamic language (the same with serialised objects and changes in version).

    So all these things are brittle - hence the inherent problems with distribution. With a dynamic language you can replace static compiler tests, with proper Unit Tests (which test the UUT for correct operation not just round pegs against square holes) with suh an approach more than type safety is ensured (of course you can do the same with a static language too, but it does make your static type checking rather redundant).

    There are approaches to distribution that try to be self healing and self configuring. JINI and JavaSpaces is one such approach, but Sun seemed to abandon it in favour of the SOA approach and SOAP in their "competition" with Microsoft. JINI is essentially a dynamic architecture, which relies on code mobility. A dynamic language is ideally suited to such an approach, Java is a bit of a half way house (did JINI actually work?).

    The simple truth is Distributed programming is hard and fraught with difficulties which is why very few systems out there actually do it to any great degree.

    Paul.
  324. Is Ruby faster to develop?[ Go to top ]

    BTW following on from my last post about distribution. With duck typing (dynamic runtime type checking) the system is more resilient to change, because if a new method is added to the remote interface existing clients will still work (as long as the methods they use are still there). With Java, any change to the interface will break all exisiting clients even if you are just adding a new method.

    Also if a method is removed, the system can still work with a dynamic language. All you need to do is deal with the "does not understand" exception. From what I remember (it's been a while since I've bothered with EJB's), if any change occur to the remote Java interface their are very few recovery options, the whole service is lost.

    Paul.
  325. Is Ruby faster to develop?[ Go to top ]

    BTW following on from my last post about distribution. With duck typing (dynamic runtime type checking) the system is more resilient to change, because if a new method is added to the remote interface existing clients will still work (as long as the methods they use are still there). With Java, any change to the interface will break all exisiting clients even if you are just adding a new method.Also if a method is removed, the system can still work with a dynamic language. All you need to do is deal with the "does not understand" exception. From what I remember (it's been a while since I've bothered with EJB's), if any change occur to the remote Java interface their are very few recovery options, the whole service is lost.Paul.

    What is your fascination with remote calls? RoR doesn't support any sort of remoting, so why bring it up? It's not central to the discussion of solid application design that I thought we were having. Enterprise features doesn't have to imply distributed computing or SOA, it can be as simple as component based design, multiple resource enlistment in transactional contexts, etc.
  326. Is Ruby faster to develop?[ Go to top ]

    In Java you can get weird errors, if you have objects of the same class and transfer them across the network and for some reason there is not exactly the same version of the class on both sides of the network. So it is a good idea to actually set the serial version uid to something based on the CVS-Header. Then you realize the incompatability at runtime earlier and more obvious. These issues have to be taken serious, but to some extent they are Java-made problems.
  327. distributed apps, take two[ Go to top ]

    In Java remote services are delivered through the Java Interface - which is a restricted form of dynamic binding anyway. If the service interface changes then you will get a runtime exception just as you would with a dynamic language (the same with serialised objects and changes in version).So all these things are brittle - hence the inherent problems with distribution.

    You're referring to RPC as implemented by RMI. Using RMI for one application to talk to another is a well-known anti-pattern.

    In Java (at least in the past five years), remote services are delivered via messaging (JMS), versionable service APIs (WS*), etc.
    The simple truth is Distributed programming is hard and fraught with difficulties which is why very few systems out there actually do it to any great degree.

    AFAICT, all business critical systems today are being built for deployment into distributed environments. Many of these systems are being built to survive failure of an entire datacenter (which happened to one of our customers two months ago).

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  328. distributed apps, take two[ Go to top ]

    In Java remote services are delivered through the Java Interface - which is a restricted form of dynamic binding anyway. If the service interface changes then you will get a runtime exception just as you would with a dynamic language (the same with serialised objects and changes in version).So all these things are brittle - hence the inherent problems with distribution.
    You're referring to RPC as implemented by RMI. Using RMI for one application to talk to another is a well-known anti-pattern..
    They nay be calling it an anti-pattern today, but for a number of years it was the "recommended approach".
    In Java (at least in the past five years), remote services are delivered via messaging (JMS), versionable service APIs (WS*), etc.
    JMS is just a messaging interface - and I agree messaging is a better approach to distribution. As for WebServices - the last time I checked (which was a number of years ago I must admit) it was being implemented as a wrapper on top of the RMI approach you call an anti-pattern above.
    The simple truth is Distributed programming is hard and fraught with difficulties which is why very few systems out there actually do it to any great degree.
    AFAICT, all business critical systems today are being built for deployment into distributed environments. Many of these systems are being built to survive failure of an entire datacenter (which happened to one of our customers two months ago).I don't claim to be an expert, but in my experience "business critical systems" tend not to use Java as the "enterprise messaging backbone". Tried and tested technology like BEA Tuxedo and IBM MQSeries tend to be reserved for this. In this type of architecture the "heavy metal" are legacy systems mostly written in C/C++ and Java is used as application glue, linking these systems together (EAI - Enterprise Application Integration) and adding presentation through a web front end.

    In truth, most Java applications are web fron ends to a database or a web front end to services written in another language. Not acknowleging this is less than honest IMO.

    Paul.
  329. distributed apps, take two[ Go to top ]

    I don't claim to be an expert, but in my experience "business critical systems" tend not to use Java as the "enterprise messaging backbone". Tried and tested technology like BEA Tuxedo and IBM MQSeries tend to be reserved for this. In this type of architecture the "heavy metal" are legacy systems mostly written in C/C++ and Java is used as application glue, linking these systems together (EAI - Enterprise Application Integration) and adding presentation through a web front end.

    In truth, most Java applications are web fron ends to a database or a web front end to services written in another language. Not acknowleging this is less than honest IMO.

    Yup, that was true five years ago. Since then, we've been seeing Tux replaced with pure Java solutions at a pretty good rate. (FYI - BEA used to be 80/20 Tux/Weblogic, they're now 40/60.)

    I can give you specific examples from my own experience:

    1) All three large package tracking firms have moved or are in the process of moving their application infrastructure to Java. One famous one (see our customer page for the name) is one of the busiest sites on the Internet, and the distributed infrastructure is pure Java.

    2) Most of the major etailers (e.g. ebay, Amazon, etc.) use a largely Java-based application infrastructure.

    3) Online banking systems from all the major banks are Java based. Same goes for online investment houses.

    4) End-to-end trading systems, from incoming feed streaming to automated order execution, are built in Java and are in production. To the best of my knowledge, the first algorithmic hedge trading system with end-to-end automation (i.e. no human interaction required, even to make buy/sell decisions) was built on Coherence.

    5) Travel systems, including for the world's largest travel / entertainment company, the web-based booking systems for two of the three largest airlines in the world, and the very backbone of the airline industry ... all built in Java.

    6) Real time risk systems for two of the four largest brokerages. Java. Distributed.

    7) Book-making (betting) systems. Don't laugh, one of our customers does over 80mm pages a day! I've been to see four of the top six in the world. All using Java.

    Container shipping management systems. Credit card transactions. Billing systems. Java.

    Maybe it's an insult, but Java is the new C++.

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  330. distributed apps, take two[ Go to top ]

    I don't claim to be an expert, but in my experience "business critical systems" tend not to use Java as the "enterprise messaging backbone". Tried and tested technology like BEA Tuxedo and IBM MQSeries tend to be reserved for this. In this type of architecture the "heavy metal" are legacy systems mostly written in C/C++ and Java is used as application glue, linking these systems together (EAI - Enterprise Application Integration) and adding presentation through a web front end.In truth, most Java applications are web fron ends to a database or a web front end to services written in another language. Not acknowleging this is less than honest IMO.Paul.

    Yes, you should definitely not claim to be an expert, because this is crap. MQSeries is SLOW, but still used. Often it's used through a JMS API interface from Websphere, etc. Many, many many enterprise backbones are built on JMS implementations now, whether they be Java implementations or merely JMS wrappers on top of a c/c++ MOM or not. Many of the core enterprise apps are being written or re-written in Java, and the others are being integrated using Java.

    Many Java applications are database-driven web apps, true, but many are not. And the ones that ARE database driven web-apps at least have an upgrade path to become full-fledged participants in the enterprise ecosystem, how about RoR apps?
  331. distributed apps, take two[ Go to top ]

    Many Java applications are database-driven web apps, true, but many are not.

    And with the number of Java apps around, the many that are not are a very large number.
    And the ones that ARE database driven web-apps at least have an upgrade path to become full-fledged participants in the enterprise ecosystem, how about RoR apps?

    This is a key point in my view. No matter how many apps turn out to remain small-scale, a certain proportion will always need to have an upgrade path. Predicting which ones will need this is not easy, which is why developing apps with a quick-but-small-scale development tool is always a risk. A risk that, in my experience, outweighs the advantage of supposedly faster development.
  332. distributed apps, take two[ Go to top ]

    Many Java applications are database-driven web apps, true, but many are not.
    And with the number of Java apps around, the many that are not are a very large number.
    And the ones that ARE database driven web-apps at least have an upgrade path to become full-fledged participants in the enterprise ecosystem, how about RoR apps?
    This is a key point in my view. No matter how many apps turn out to remain small-scale, a certain proportion will always need to have an upgrade path. Predicting which ones will need this is not easy, which is why developing apps with a quick-but-small-scale development tool is always a risk. A risk that, in my experience, outweighs the advantage of supposedly faster development.

    I worked on a project for a big wireless telecome where it took two years to finally and completely migrate from a core module that started as a proof-of-concept.

    I've seen this too many times. You give a demo of a prototype and the customers goes, just add a handful of features and that's it! I've replaced VB systems because the VB system broke or was a nightmare to maintain.

    This is why even my smallest app, 2 pages is built on our Struts/Spring/Hibernate core. I know the odds of this becoming a production system is better than good.
  333. distributed apps, take two[ Go to top ]

    Yes, you should definitely not claim to be an expert, because this is crap.
    OK, back to the insults...
    MQSeries is SLOW, but still used. Often it's used through a JMS API interface from Websphere, etc. Many, many many enterprise backbones are built on JMS implementations now, whether they be Java implementations or merely JMS wrappers on top of a c/c++ MOM or not. Many of the core enterprise apps are being written or re-written in Java, and the others are being integrated using Java.

    Last time I worked on a true "enterprise application" was 2003. That used Tuxedo as the messaging backbone. My experience just doesn't reflect what your are saying. Also in my experience true data centers tend to be pretty conservative places. In many of them Unix/C/C++ struggle for a foot hold and they are still using things like COBOL and CIC's. I just don't believe things have changed as quickly as you make out.
    Many Java applications are database-driven web apps, true, but many are not. And the ones that ARE database driven web-apps at least have an upgrade path to become full-fledged participants in the enterprise ecosystem, how about RoR apps?
    I am a freelance consultant, so it is my business to know my market. It is usually managers who make technology choice decisions long before they hire developers. In their view Java is seen as web technology and as EAI technology. You may like to believe that Java is at the centre of the IT universe - but just puruse the average IT jobs board and you will see that most Java positions are for Web/database and web/EAI.

    So that brings us to RoR - I'll say it one last time. I am not advocating the use of Ruby, but for Agile development a dynamic language offers several advantages. True stable enterprise services (payroll, billing etc) tend to be pretty fixed in their requirements, but people centric systems like workflow and application databases tend to be very fluid. For these applications companies need to move quickly - the development cycle is ideally a few months and requirements churn happens all the time. EAI is about getting the best of both worlds. Stable corporate services with development cycles of over a year (in C/C++ in my experience) and quickly changing business unit applications developed in a couple of months (Java). For the EAI role Ruby and RoR is equally well suited if not better suited then Java (IMO better suited). Even if Java moved into the datacenter - then through language agnostic interfaces (messaging, webservices etc) Ruby could still be used to deliver business applications quickly.

    Paul.
  334. distributed apps, take two[ Go to top ]

    Even if Java moved into the datacenter - then through language agnostic interfaces (messaging, webservices etc) Ruby could still be used to deliver business applications quickly.Paul.

    Yes, but yet again, delivering applications quickly is just one aspect of what (in my view) a developer should be doing. They should also (in my view) be delivering applications which can be supported long term and maintained, often by different developers. Others may not consider this important. I do. The problem with the way that development can often be done with dynamic languages is for developers (or teams) to write their own clever abstractions; to use their own neat tricks; to use this-years fashionable DSL. And, of course, you can imagine the horrors that result when two different teams with different abstractions try and combine code at some point. (Actually, I don't have to imagine this - I have seen such things in Smalltalk applications in the 80s.) These abstractions allow rapid development, but can be a serious problem for other developers or teams to decode and deal with. In a powerful and expressive language like Ruby it can be even hard to locate all places where a class is defined - a class can have different methods depending on which branch of logic is followed. In my view, the expressiveness and flexibility of dynamic languages can often be outweighed by the work required to document and test.

    I am not trying to insult, or argue too much - just to express a view that I believe that at least some of us with considerable experience of both static and dynamic languages hold.
  335. distributed apps, take two[ Go to top ]

    Even if Java moved into the datacenter - then through language agnostic interfaces (messaging, webservices etc) Ruby could still be used to deliver business applications quickly.Paul.
    Yes, but yet again, delivering applications quickly is just one aspect of what (in my view) a developer should be doing.
    I understand your view, but it is the view of the business that counts.
    They should also (in my view) be delivering applications which can be supported long term and maintained, often by different developers. Others may not consider this important. I do. The problem with the way that development can often be done with dynamic languages is for developers (or teams) to write their own clever abstractions; to use their own neat tricks; to use this-years fashionable DSL. And, of course, you can imagine the horrors that result when two different teams with different abstractions try and combine code at some point.

    I am looking at this from purely an Agile perspective; XP to be precise. My goal is to produce the simplest thing that can possibly work - whilst meeting my customer requirements. No clever abstractions, clean simple code produced test driven in close communication with my customer (onsite customer). Similar to what use to be called RAD.
    (Actually, I don't have to imagine this - I have seen such things in Smalltalk applications in the 80s.) These abstractions allow rapid development, but can be a serious problem for other developers or teams to decode and deal with. In a powerful and expressive language like Ruby it can be even hard to locate all places where a class is defined - a class can have different methods depending on which branch of logic is followed.)
    Yes, but XP and Agile development didn't exist in the 80's. In fact it arose out of the precise chaos you described in Smalltalk. Kent Beck the inventor of XP is a Smalltalk programmer.
    In my view, the expressiveness and flexibility of dynamic languages can often be outweighed by the work required to document and test. I am not trying to insult, or argue too much - just to express a view that I believe that at least some of us with considerable experience of both static and dynamic languages
    I practice XP with Java today. I write JUnit test code before I write application code. We have over 600 unit tests; we have as much unit test code as real code. We then go on to use Watir and Ruby to perform automated user acceptance testing, by automating the browser. Contrary to popular belief XP is an extremely disciplined approach, based on close customer involvement, and explicit feedback through testing.

    For rapidly changing requirements and short development cycles XP is ideal. Also the discipline of XP allows you to take advantage of the benefits of a dynamic language without the downsides (like I said XP came from Smalltalk). Of course if you do not follow such a disciplined approach, I would not advise the use of a dynamic language. Thinking back on how I use to develop before (no real testing), I definitely would not have used a dynamic language like Ruby.

    I'm talking about a completely different development philosophy.

    Paul.
  336. distributed apps, take two[ Go to top ]

    I understand your view, but it is the view of the business that counts.

    That is what I am basing my view on - the businesses I deal with.
    I am looking at this from purely an Agile perspective; XP to be precise. My goal is to produce the simplest thing that can possibly work - whilst meeting my customer requirements. No clever abstractions, clean simple code produced test driven in close communication with my customer (onsite customer). Similar to what use to be called RAD.

    I am sure it is your goal. However, I have seen the way others work :)
    Yes, but XP and Agile development didn't exist in the 80's. In fact it arose out of the precise chaos you described in Smalltalk. Kent Beck the inventor of XP is a Smalltalk programmer.

    I know, and there is still major controversy about the use and value of XP, and so it is by no means universally used. We are not dealing with an ideal world.
    Of course if you do not follow such a disciplined approach, I would not advise the use of a dynamic language. Thinking back on how I use to develop before (no real testing), I definitely would not have used a dynamic language like Ruby.I'm talking about a completely different development philosophy.Paul.

    I think we are agreeing! The problem is the use of dynamic languages without a disciplined approach. My view is that we live in a less-than perfect world where many will not be using such a disciplined approach, and don't share this development philosophy. Java is a very tolerant language!
  337. distributed apps, take two[ Go to top ]

    blockquote>I think we are agreeing! The problem is the use of dynamic languages without a disciplined approach. My view is that we live in a less-than perfect world where many will not be using such a disciplined approach, and don't share this development philosophy. Java is a very tolerant language!Agreed. Life is about choices - I'm firmly in the Agile camp.

    Paul.
  338. distributed apps, take two[ Go to top ]

    Yes, you should definitely not claim to be an expert, because this is crap.
    OK, back to the insults...
    MQSeries is SLOW, but still used. Often it's used through a JMS API interface from Websphere, etc. Many, many many enterprise backbones are built on JMS implementations now, whether they be Java implementations or merely JMS wrappers on top of a c/c++ MOM or not. Many of the core enterprise apps are being written or re-written in Java, and the others are being integrated using Java.
    Last time I worked on a true "enterprise application" was 2003. That used Tuxedo as the messaging backbone. My experience just doesn't reflect what your are saying. Also in my experience true data centers tend to be pretty conservative places. In many of them Unix/C/C++ struggle for a foot hold and they are still using things like COBOL and CIC's. I just don't believe things have changed as quickly as you make out.
    Many Java applications are database-driven web apps, true, but many are not. And the ones that ARE database driven web-apps at least have an upgrade path to become full-fledged participants in the enterprise ecosystem, how about RoR apps?
    I am a freelance consultant, so it is my business to know my market. It is usually managers who make technology choice decisions long before they hire developers. In their view Java is seen as web technology and as EAI technology. You may like to believe that Java is at the centre of the IT universe - but just puruse the average IT jobs board and you will see that most Java positions are for Web/database and web/EAI.So that brings us to RoR - I'll say it one last time. I am not advocating the use of Ruby, but for Agile development a dynamic language offers several advantages. True stable enterprise services (payroll, billing etc) tend to be pretty fixed in their requirements, but people centric systems like workflow and application databases tend to be very fluid. For these applications companies need to move quickly - the development cycle is ideally a few months and requirements churn happens all the time. EAI is about getting the best of both worlds. Stable corporate services with development cycles of over a year (in C/C++ in my experience) and quickly changing business unit applications developed in a couple of months (Java). For the EAI role Ruby and RoR is equally well suited if not better suited then Java (IMO better suited). Even if Java moved into the datacenter - then through language agnostic interfaces (messaging, webservices etc) Ruby could still be used to deliver business applications quickly.Paul.

    See Cameron's post. He's in a better position than either of us to say what large enterprises are using in their datacenters.

    I think it's unlikely that lots of independent contractors are brought in to work on an enterprise app development team. Large consulting firm (like an IBM, etc) yes, but an individual? You may be skewed by what you're being hired to do. For myself, I've been building large-scale Java apps-as-products for 6 years or so, and integrating them with large enterprises (well mostly in my last job, this product isn't in production yet). I can tell you that our large customers definitely had Java running in their datacenters. Believe me, I wish they didn't, 'cause they already had standards in place (like "it has to run on WebSpehere") which were much more trouble than if we were the first ones.
  339. That's not my experience[ Go to top ]

    In Java remote services are delivered through the Java Interface - which is a restricted form of dynamic binding anyway. If the service interface changes then you will get a runtime exception just as you would with a dynamic language (the same with serialised objects and changes in version).So all these things are brittle - hence the inherent problems with distribution.

    You're referring to RPC as implemented by RMI. Using RMI for one application to talk to another is a well-known anti-pattern..

    They nay be calling it an anti-pattern today, but for a number of years it was the "recommended approach".
    In Java (at least in the past five years), remote services are delivered via messaging (JMS), versionable service APIs (WS*), etc.
    JMS is just a messaging interface - and I agree messaging is a better approach to distribution. As for WebServices - the last time I checked (which was a number of years ago I must admit) it was being implemented as a wrapper on top of the RMI approach you call an anti-pattern above.
    The simple truth is Distributed programming is hard and fraught with difficulties which is why very few systems out there actually do it to any great degree.

    AFAICT, all business critical systems today are being built for deployment into distributed environments. Many of these systems are being built to survive failure of an entire datacenter (which happened to one of our customers two months ago).

    I don't claim to be an expert, but in my experience "business critical systems" tend not to use Java as the "enterprise messaging backbone". Tried and tested technology like BEA Tuxedo and IBM MQSeries tend to be reserved for this. In this type of architecture the "heavy metal" are legacy systems mostly written in C/C++ and Java is used as application glue, linking these systems together (EAI - Enterprise Application Integration) and adding presentation through a web front end.

    In truth, most Java applications are web fron ends to a database or a web front end to services written in another language. Not acknowleging this is less than honest IMO.

    Paul.
    My first hand experience the last 5 years doesn't back that assertion. In 1999, I was working on location intelligent mobile platform and it definitely wasn't "dump some tables to a webpage." There was quite a bit of business logic to track users GPS location, and lots of integration with third party systems. After that I worked for Superpages.com and it also wasn't dump data to a webpage. In the case of superpages, we had to support internationalization and provide an easy way to create new co-branded sites. Again, lots of business logic that requires a domain model that is well thoughtout and flexible. After that, I worked on financial pre-trade compliance. The same data goes through several different systems and those systems must integrate smoothly. For that one needs a well thoughout object model because there's more than one input, several database models and several outputs. Now I'm mostly doing EJB stuff because it's all about integration.

    I don't know about other markets, but in Boston MA, a decent percentage of the work is integration. I don't have any numbers to back it up, so I won't make bogus claims. Depending on a person's area of focus, it might look like Javaland is most front-end webpages, or large scale integrations.

    Going by my experience, one could get a skewed perspective and think, "ROR is pointless for integration." If I was building database driven webapp that didn't need to integrate with other systems, I'd atleast give ROR a look. Luckily for me, I no longer work on that kind of application. The thing I find noisy about ROR is over stating the benefits.

    my 2 bits

    peter
  340. That's not my experience[ Go to top ]

    In Java remote services are delivered through the Java Interface - which is a restricted form of dynamic binding anyway. If the service interface changes then you will get a runtime exception just as you would with a dynamic language (the same with serialised objects and changes in version).So all these things are brittle - hence the inherent problems with distribution.
    You're referring to RPC as implemented by RMI. Using RMI for one application to talk to another is a well-known anti-pattern..
    They nay be calling it an anti-pattern today, but for a number of years it was the "recommended approach".
    In Java (at least in the past five years), remote services are delivered via messaging (JMS), versionable service APIs (WS*), etc.
    JMS is just a messaging interface - and I agree messaging is a better approach to distribution. As for WebServices - the last time I checked (which was a number of years ago I must admit) it was being implemented as a wrapper on top of the RMI approach you call an anti-pattern above.
    The simple truth is Distributed programming is hard and fraught with difficulties which is why very few systems out there actually do it to any great degree.
    AFAICT, all business critical systems today are being built for deployment into distributed environments. Many of these systems are being built to survive failure of an entire datacenter (which happened to one of our customers two months ago).
    I don't claim to be an expert, but in my experience "business critical systems" tend not to use Java as the "enterprise messaging backbone". Tried and tested technology like BEA Tuxedo and IBM MQSeries tend to be reserved for this. In this type of architecture the "heavy metal" are legacy systems mostly written in C/C++ and Java is used as application glue, linking these systems together (EAI - Enterprise Application Integration) and adding presentation through a web front end.In truth, most Java applications are web fron ends to a database or a web front end to services written in another language. Not acknowleging this is less than honest IMO.Paul.
    My first hand experience the last 5 years doesn't back that assertion. In 1999, I was working on location intelligent mobile platform and it definitely wasn't "dump some tables to a webpage." There was quite a bit of business logic to track users GPS location, and lots of integration with third party systems. After that I worked for Superpages.com and it also wasn't dump data to a webpage. In the case of superpages, we had to support internationalization and provide an easy way to create new co-branded sites. Again, lots of business logic that requires a domain model that is well thoughtout and flexible. After that, I worked on financial pre-trade compliance. The same data goes through several different systems and those systems must integrate smoothly. For that one needs a well thoughout object model because there's more than one input, several database models and several outputs. Now I'm mostly doing EJB stuff because it's all about integration.I don't know about other markets, but in Boston MA, a decent percentage of the work is integration. I don't have any numbers to back it up, so I won't make bogus claims. Depending on a person's area of focus, it might look like Javaland is most front-end webpages, or large scale integrations.Going by my experience, one could get a skewed perspective and think, "ROR is pointless for integration." If I was building database driven webapp that didn't need to integrate with other systems, I'd atleast give ROR a look. Luckily for me, I no longer work on that kind of application. The thing I find noisy about ROR is over stating the benefits.my 2 bitspeterHi Peter,
    In truth, my experience has been varied too. Having said that in most cases where I've used EJB's they haven't been needed. But for some apps EJB is the "sweet spot".

    Like I said before if the only tool you have in your tool box is an Hammer, then every problem you come across will look like a Nail. Technology selection is about making the right choice - Ruby and RoR is right for some circumstances wrong for others.

    BTW. Don't under estimate the integraion (EAI) capabilities of a dynamic language like Ruby - look back at my previous posts.

    Paul.
  341. That's not my experience[ Go to top ]

    In truth, my experience has been varied too. Having said that in most cases where I've used EJB's they haven't been needed. But for some apps EJB is the "sweet spot".

    Like I said before if the only tool you have in your tool box is an Hammer, then every problem you come across will look like a Nail. Technology selection is about making the right choice - Ruby and RoR is right for some circumstances wrong for others.

    BTW. Don't under estimate the integraion (EAI) capabilities of a dynamic language like Ruby - look back at my previous posts.

    Paul.

    I've definitely seen EJB misused also. There's nothing I can say that hasn't already been said about abuse of EJB. So far about half the jobs I've had the last 5 years, half of them used the right technology to solve the problem. The other half misuse technology because some CTO/CEO made a decision. that's a difficult environment to work in, and it has very little to do with the inherent value of a given technology. it's the sad out come of good marketing.

    peter
  342. That's not my experience[ Go to top ]

    I don't know about other markets, but in Boston MA, a decent percentage of the work is integration. I don't have any numbers to back it up, so I won't make bogus claims. Depending on a person's area of focus, it might look like Javaland is most front-end webpages, or large scale integrations.

    The company that writes the software that runs a number of the exchanges is in Boston (actually, Lexington). It's Java.

    Wellington Management, Fidelity, Putnam Investments, various arms of JP and DB, etc. are all in Boston. They're all using Java for their LOB systems.

    Integration is valuable to companies, so it's not surprising that a lot of Java work is in integration. But there's a lot more going on around here ..

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  343. That's not my experience[ Go to top ]

    I don't know about other markets, but in Boston MA, a decent percentage of the work is integration. I don't have any numbers to back it up, so I won't make bogus claims. Depending on a person's area of focus, it might look like Javaland is most front-end webpages, or large scale integrations.

    The company that writes the software that runs a number of the exchanges is in Boston (actually, Lexington). It's Java.

    Wellington Management, Fidelity, Putnam Investments, various arms of JP and DB, etc. are all in Boston. They're all using Java for their LOB systems.

    Integration is valuable to companies, so it's not surprising that a lot of Java work is in integration. But there's a lot more going on around here ..

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java

    agree 100%. South boston area also has a lot of financial firms, so it's pretty diverse. Now if only more stuff moved out to westborough area, I could go back to doing trading systems and not have to commute 4-5 hours a day :)

    peter
  344. Don´t blame - learn ![ Go to top ]

    Why would someone program with Java today ?
    1) Because he didnt give Ruby a try
    2) Because it meets his requirements = EE
    3)Because it meets his requirements = SE
    4)Because it meets his requirements = ME
    5)Because he's not building web apps, but rather applications that might currently have or have as one of its UIs an HTML browser based UI.
    6) Because he already has a set of frameworks, etc that make him [almost] just as productive as RoR [on initial development].
    7) Because he is looking long term (and maintenance and change and adaptability)
    8) Because, in the past, he let the db drive the design of his apps and he learned it cost him in the long run.
    9) Because he read what Bruce said and saw him saying that RoR was a niche technology.


    As for #1, don't you mean RoR?
  345. Don´t blame - learn ![ Go to top ]

    Why would someone program with Java today ?1) Because he didnt give Ruby a try2) Because it meets his requirements = EE
    3)Because it meets his requirements = SE4)Because it meets his requirements = ME5)Because he's not building web apps, but rather applications that might currently have or have as one of its UIs an HTML browser based UI.6) Because he already has a set of frameworks, etc that make him [almost] just as productive as RoR [on initial development].7) Because he is looking long term (and maintenance and change and adaptability)8) Because, in the past, he let the db drive the design of his apps and he learned it cost him in the long run.9) Because he read what Bruce said and saw him saying that RoR was a niche technology.As for #1, don't you mean RoR?

    No, I mean Ruby (pure).

    You are mostly correct, to the points you have extended. But I only wanted to focus on the default Language capabilities, because you deal with them all the time. Sure, you can use Spring, WebWork, Hibernate... (I do as well), but basicly you program using "Java" even when you are resuing framework-code.

    Also, I used EE and not JEE :)
    In an Enterpr. Environment using servers with different OS´s ,distributed Architecture, Messaging, high Performance requirements etc. etc. (this is for my sense EE), Java will remain a good choice.
  346. Rubyforge[ Go to top ]

    When comparing the activity on Sourceforge, you have to take into account that there are some other platforms like that and that the choice between these depends to some extent on the language.
    For Ruby-stuff you find a lot of projects on http://www.rubyforge.org/
    There is also savannah.gnu.org, tigris.org and probably quite a few others. I have no doubt that sourceforge.net is hosting quite a lot more projects than the others, but it is dangerous to count on sourceforge alone for telling about the popularity of programming languages.
  347. Rubyforge[ Go to top ]

    I have no doubt that sourceforge.net is hosting quite a lot more projects than the others, but it is dangerous to count on sourceforge alone for telling about the popularity of programming languages.

    True. But java has a few other hosting sites too.
  348. This can't be about Java v. Rails. It's either Java v Ruby or <insert-favourite-java-based-framework-here> v Rails.

    If it's Java v Rails, I don't think it's fair to compare a scripting lang with a typesafe one.

    If it's Rails v all java based frameworks, well, there are so many of them and it's not fair to make a call on which is more productive until you've tryed them all along with Rails.

    Of course, there's no reason why someone should not implement Rails in java and it won't be substantially different, toher than the "Casts and semicolons" that somebody mentioned above.
  349. last words[ Go to top ]

    In terms of growing competition, it is important to keep an open and clean mind on our business.

    This means in my eyes: Using the correct Language+Tools for the correct jobs. Depending on the case the correct choice could be Java, in other not. An obvious case where Java and other OOP languages are applications which require declarative programming such as Prolog (rule based languages). Examples for this are: AI systems, Reasoners but also radiqly changing business models containing countles if-else statements nested into each other.

    Like I said, I realy believe that Java will not loose in importance, I think the areas where Java will be used in future will be more specialised then today - it will be mostly the Enterprise.

    This discussion was very controversal, but I enjoyed arguing with you guys. If you want to continoue talking or if you think you have still unfinished business with me, feel free to write an email: andreas dot andreakis at gmx dot de

    cheers and cu all in another thread,
    Andreas
  350. last words[ Go to top ]

    I don't think any said that they wouldn't consider alternatives. I'm originally from a C/Unix background and I've covered C,C++, and Java across Windows, various Unix boxes, OS/2, and even a bit of VMS.

    I'll wouldn't hesitate go jump from Java to whatever the next big thing is.

    I just don't think the next big thing is ROR or Ruby.
  351. Java vs Ruby/ROR FAQ[ Go to top ]

    I propose we create a Java vs Ruby/ROR FAQ based on this thread:

    Q. Can Ruby/ROR solve the problems we currently solve with Java?
    A. No, but JSE 5/6 does not include GroupLayout/Portlets.

    Q. Can Ruby/ROR solve the problems we currently solve with Java?
    A. No, but JCP is ineffective - look at EJB.

    Q. Can Ruby/ROR solve the problems we currently solve with Java?
    A. No, but look how great C# 3.0 is going to be.

    Q. Can Ruby/ROR solve the problems we currently solve with Java?
    A. No, but Java is not Open Source.

    Q. Can Ruby/ROR solve the problems we currently solve with Java?
    A. No, but you're not riding the crest of the wave.

    Q. Can Ruby/ROR solve the problems we currently solve with Java?
    A. No, but it's easy, intuitive and fun.

    Q. Can Ruby/ROR solve the problems we currently solve with Java?
    A. No, but you're just being a close minded Java fan-boy.
  352. ...just as this thread. I said I´ll be off, but I´m back to express some thoughts I had recently on this topic.

    I think the reason why people are naturally closed to new and alternative approaches is simply because they feel comfortable to a current technology. Because it solves a bunch of problems in a common/used way and thus there is no need to consider anythink else - Yes, I totaly agree with Mr. Tate´s message.

    Take Java:
    We are fully aware of Java´s advantages. Thus, we know that Java is suitable for a wide range of usecases, starting from scintific/algorithmic-intensive appls to Business-aware -Webapps / enterprise apps. We also know that Java is superiour to C++ for the same usecases.

    Now do the following experiment:
    Go to a C++ Community and try to save their souls. Tell them that Java can solve a bunch of simmilar problems easier and as performable as with C++.
    I can garantee you will get slapped. And you know why ?? Because:
    1) with Java you can´t access hardware resources
    2) with Java you work with a VM and thus your code will be extremly slow
    3) with Java you dont have mult. inheritence
    4) with java you can´t use pointers (pointers are fantastic !!!)
    .
    .
    .
    100) Java has a weird animal as a mascot

    People will find more then 100 reasons why c++ is superior to Java and thus there is no need for them to consider Java at all. Notice that c++ is #2 @ sourceforge. I know a lot of people personaly, who still feel very save using C++ and dont have any idea that Java is a multi-billion market. I still hear statements like: "You can forget Java if it comes to performance"

    You would say: are they blind ????

    Maybe they are, but their business is done. They have a task, programm it in C++ and it works, they get money / respect and are happy.

    But wait a moment.....isnt this applyable to every language out there ?
    If you do the same experiment to any other Communities like PHP, Ruby, C#, Prolog, Fortran,... you will always be told how unsuitable Java is (for the usecases this languages adress) - at least from the majority of people.

    Is language comparition somethink like comparing religions ? Which is better beeing beeing catholic or buddhistic ? In both ways you will reach heaven ..... but on different ways. Even thue the comparition is a bit bizarre, I think it is appliable to programming languages.

    Using a language like C++ means more pain then using Java, but with both you will get the job done, with both you will reach heaven.


    Now close your eyes, relax and imagine yourself beeing aware of the advantages of Ruby+RoR for a specific set of usecases, knowing that you do the same job in a cleaner way, cleaner than C++ and Java. Now get to a poppular Java Community such as therserverside and try to save their souls.........is this a déjá vu ?


    cheers,
    Andreas
  353. Now get to a poppular Java Community such as therserverside and try to save their souls.........is this a déjá vu ?

    Boy did I see that question coming ;-)
  354. Now close your eyes, relax and imagine yourself beeing aware of the advantages of Ruby+RoR for a specific set of usecases, knowing that you do the same job in a cleaner way, cleaner than C++ and Java. Now get to a poppular Java Community such as therserverside and try to save their souls.........is this a déjá vu ?cheers,Andreas

    This might almost be compelling, if it weren't for 2 things:

    1) You could replace Ruby above with Python, Smalltalk, Lisp, etc. and it would be just as valid, and yet just as unlikely.

    2) Ruby's been around LONGER than Java!!!! It never caught on before. Is RoR really that incredible that it can make or break the whole language and platform? I think not.
  355. Ruby's been around LONGER than Java!!!! It never caught on before. Is RoR really that incredible that it can make or break the whole language and platform? I think not.
    Well you definately can't build Rails using Java. Have you taken a look at the ActiveRecord design? It makes extensive use of metaprogramming and late-binding to faciliate the RoR DRY principle. Java just doesn't have a meta model (MetaClass) and it is static langauge so everything must be defined at compile time, no late binding (well not much).

    Ruby is not for everyone, and dispite being harangued on this thread I have never advocated Ruby specifically for anything.

    What I have been trying to say (in between responding to the insults) is:

    1. If you have access to your customer (onsite customer)and a high degree of requirements flux
    2. If you use an Agile approach and perform practies like Test Driven Development
    3. If you are fimilar with dynamic languages and their advantages and disadvantages
    4. If your customer just want a presentation on top of a database with minimal business logic.

    Then you will be far more productive with a dynamic language and a framework like RoR then Java/Spring/Hibernate. IMO this is just a fact.

    No these criteria do not apply to all under all curcumstances, but if the only tool you have in your tool box is a Hammer, then everything will look like a Nail.

    Incidently all this talk about industrial strength "enterprise wide" applications. Where are they? I've been building J2EE apps since 1997 and I've still yet to see true enterprise components (actually I have on a couple of occasions, but both of those examples used BEA Tuxedo (C/C++) messaging as a backbone).

    After all the promises from EJB1.0 to today SOAP and SOA are now being touted as the "ideal" mechanism for enterprise wide business services distribution. Let's assume that this is true for a moment and re-consider RoR constraint 4 above. Take a look at the ActiveRecord design in Rails and imagine an ActiveService component that did the same thing for WSDL/SOAP services that ActiveRecord does for SQL databases.

    So again in the right hands RoR would be much more productive for these types of applications too, when compared to say BEA Weblogic/Hibernate.

    Take a look for yourselves - and you will see that what I and others are saying holds water.

    Paul.
  356. What the world doesn't need now is another programming language.
  357. I could discuss RoR and current Java frameworks, but the following statements (from various RoR guys) evoke images of cluless salespeople at best, Kool-aid drinkers at worst:
    Then you will be far more productive with a dynamic language and a framework like RoR then Java/Spring/Hibernate. IMO this is just a fact.
    Take a look for yourselves - and you will see that what I and others are saying holds water.
    And you do need to follow the buzz. 200K downloads in under a year is significant. (I think that's about right...)
  358. 4. If your customer just want a presentation on top of a database with minimal business logic.
    Doesn't this violate the DRY principle? Or is it really RO (repeating others) so it is ok?

    Incidently all this talk about industrial strength "enterprise wide" applications. Where are they?
    Part of it is because the tool (EJB 1-2) didn't fully fit the job (It worked for some things). I think the main reason is because people continue to avoid OO/componetizing on a larger scale and do things like "putting a web front end on a database". They continue to build bottom up or top down. Not middle out. It's not buildings or clouds or lightening we are making. :)
  359. 4. If your customer just want a presentation on top of a database with minimal business logic.
    Doesn't this violate the DRY principle? Or is it really RO (repeating others) so it is ok?
    Incidently all this talk about industrial strength "enterprise wide" applications. Where are they?
    Part of it is because the tool (EJB 1-2) didn't fully fit the job (It worked for some things). I think the main reason is because people continue to avoid OO/componetizing on a larger scale and do things like "putting a web front end on a database". They continue to build bottom up or top down. Not middle out. It's not buildings or clouds or lightening we are making. :)
    Finally - a response that isn't an insult.

    No, I think the reason why people haven't distributed their business logic is mainly due to the inherent difficulties of distributed programming. Martin's Fowler's first rule of distributed programming is don't do distributed programming.

    It took me a while to catch on, but now I tend to agree. Also SOA relies pretty much on BUFD (Big Upfront Design) and if you come from an Agile background you'll know that BUFD tends to lead to fragile, non-optimal and difficult to maintain systems. In truth, how are you meant to know what your service interface should be in the abscence of real clients and real requirements - you don't so what you do is guess and over engineer.

    The DRY principle across an organisation is an enviable goal, but IMO it is only possible through incremental change where services emerge over time through refactoring.

    It works like this you build application A. You then go on to build application B introducing redundancy - once both A and B are stable you are in a position to mine out the common code and gain re-use either through a shared library or a shared service. Re-use of stable code is possible, but trying to re-use a moving target is a configuration nightmare. Which incidently leads me to the 8 fallicy's of distributed programming:

    http://today.java.net/jag/Fallacies.html

    So in short distributed computing is difficult. Asynchronous messaging makes it easier, but doesn't work that well for interactive applications. I believe dynamic languages can help here too, by utilising late binding and mobile code. But that is a whole different discussion.

    Paul.
  360. Finally - a response that isn't an insult.
    I can provide one if it makes you feel more at home. :)
    No, I think the reason why people haven't distributed their business logic is mainly due to the inherent difficulties of distributed programming. Martin's Fowler's first rule of distributed programming is don't do distributed programming.
    Well, I was thinking (as best as I can feeling kinda ill) more about distributing the business logic (passing it around and reusing it - JINI, Webstart, etc.) not distributed business logic (aka EJB 1/2).
    Also SOA relies pretty much on BUFD (Big Upfront Design) and if you come from an Agile background you'll know that BUFD tends to lead to fragile, non-optimal and difficult to maintain systems.
    Not all, but probably most. I'm not advocating SOA BUFD. Oddly, data driven design is typically BUFD.
    The DRY principle across an organisation is an enviable goal, but IMO it is only possible through incremental change where services emerge over time through refactoring.
    Yes. I agree. But the problem is, that is isn't done. For example, Customers have a db that is accessed via batch. Then they want to webiffy it and have someone slap a web UI on it. Instead refactoring the batch as needed and coming up with a common interface to the persistance layer.
    It works like this you build application A. You then go on to build application B introducing redundancy - once both A and B are stable you are in a position to mine out the common code and gain re-use either through a shared library or a shared service.
    If you use inconsistant technologies, then it makes this even more difficult. That is why people like Steve, David, etc. are advocating sticking with Java for the interm phase even though it seems less productive. In the long run, it is less.

    Sorry, if this is not clear. I am a wee bit woozy.
  361. Finally - a response that isn't an insult.
    I can provide one if it makes you feel more at home. :)
    No, I think the reason why people haven't distributed their business logic is mainly due to the inherent difficulties of distributed programming. Martin's Fowler's first rule of distributed programming is don't do distributed programming.
    Well, I was thinking (as best as I can feeling kinda ill) more about distributing the business logic (passing it around and reusing it - JINI, Webstart, etc.) not distributed business logic (aka EJB 1/2).
    Also SOA relies pretty much on BUFD (Big Upfront Design) and if you come from an Agile background you'll know that BUFD tends to lead to fragile, non-optimal and difficult to maintain systems.
    Not all, but probably most. I'm not advocating SOA BUFD. Oddly, data driven design is typically BUFD.
    The DRY principle across an organisation is an enviable goal, but IMO it is only possible through incremental change where services emerge over time through refactoring.
    Yes. I agree. But the problem is, that is isn't done. For example, Customers have a db that is accessed via batch. Then they want to webiffy it and have someone slap a web UI on it. Instead refactoring the batch as needed and coming up with a common interface to the persistance layer.
    It works like this you build application A. You then go on to build application B introducing redundancy - once both A and B are stable you are in a position to mine out the common code and gain re-use either through a shared library or a shared service.
    If you use inconsistant technologies, then it makes this even more difficult. That is why people like Steve, David, etc. are advocating sticking with Java for the interm phase even though it seems less productive. In the long run, it is less.Sorry, if this is not clear. I am a wee bit woozy.

    I think you mean "more" in the long run, but right on target otherwise. To restate my position:

    Other things claim ot be faster than Java for web development. At my company, some time ago, there were rumblings of using Code Fusion because it could be faster. My contention was that it may very well be faster, but I can crank out even small applications *almost* as quickly. But what the Struts/Spring/Hibernate(SSH) may lack in raw development speed, it makes up for in maintainability, fammilarity, reuse, and flexibility. Our SSH framework has a slew of functions both homegrown and provided by the trifecta of OS upon which it is based, that provide out of the box value. Also, we can easily swap one item for another. For example, I've been reading up on JSF and will probably use it for my next project, replacing Struts.

    While I understand the siren's call of faster development, my experience has shown that a slightly more measured pace ultimately yields bigger dividends of productivity down the road. Just call it delayed gratification.

    I haven't heard anything that says that ROR can replace this stuff. If I'd said, I use Struts, what can JSF do for me? I'll get a comparison on Struts and JSF. If I'd said "I use OSCache, what can ehcache" do for me or even "I use Spring, what can Hivemind do for me?" I'd get feature for feature comparisons followed by a discussion of how I would handled a given feature in the alternative.

    But now so for ROR. I've offered a list of itemsour current codebase does and all I get is "closeminded","XML is scripting", and "You caaaannn't handled the truth!"

    Right now, today, I have a set of code that scales from smaller to mid-sized projects(more main work). It'll probably go larger, but we haven't had any larger ones yet.

    I see no value in using multiple solutions when one works.
  362. I think you mean "more" in the long run, but right on target otherwise. To restate my position:
    Yeah, I guess it wasn't clear on what I was point at. :) I meant doing it with Java is less in the long run.
  363. 4. If your customer just want a presentation on top of a database with minimal business logic.
    Doesn't this violate the DRY principle? Or is it really RO (repeating others) so it is ok?
    Incidently all this talk about industrial strength "enterprise wide" applications. Where are they?
    Part of it is because the tool (EJB 1-2) didn't fully fit the job (It worked for some things). I think the main reason is because people continue to avoid OO/componetizing on a larger scale and do things like "putting a web front end on a database". They continue to build bottom up or top down. Not middle out. It's not buildings or clouds or lightening we are making. :)
    Finally - a response that isn't an insult.No, I think the reason why people haven't distributed their business logic is mainly due to the inherent difficulties of distributed programming. Martin's Fowler's first rule of distributed programming is don't do distributed programming.It took me a while to catch on, but now I tend to agree. Also SOA relies pretty much on BUFD (Big Upfront Design) and if you come from an Agile background you'll know that BUFD tends to lead to fragile, non-optimal and difficult to maintain systems. In truth, how are you meant to know what your service interface should be in the abscence of real clients and real requirements - you don't so what you do is guess and over engineer.The DRY principle across an organisation is an enviable goal, but IMO it is only possible through incremental change where services emerge over time through refactoring.It works like this you build application A. You then go on to build application B introducing redundancy - once both A and B are stable you are in a position to mine out the common code and gain re-use either through a shared library or a shared service. Re-use of stable code is possible, but trying to re-use a moving target is a configuration nightmare. Which incidently leads me to the 8 fallicy's of distributed programming:http://today.java.net/jag/Fallacies.htmlSo in short distributed computing is difficult. Asynchronous messaging makes it easier, but doesn't work that well for interactive applications. I believe dynamic languages can help here too, by utilising late binding and mobile code. But that is a whole different discussion.Paul.

    Again, you don't need distributed objects to achieve reuse. I agree that it should be avoided at all costs. What you DO need is a rich domain model and reusable (local) services built on top of those models. Note that ActiveRecord builds a domain model of sorts, but ties you too closely to the db schema and makes the models too anemic for my tastes.

    For services, you're often not the one defining the interface. Often it's a legacy system and they're exposing what it can do... It's up to you to work around that.

    But then again, I also think this SOA stuff is pretty fluffy, and batch zip files with FTP work pretty well ;-)
  364. distributed applications[ Go to top ]

    No, I think the reason why people haven't distributed their business logic is mainly due to the inherent difficulties of distributed programming. Martin's Fowler's first rule of distributed programming is don't do distributed programming.

    Martin Fowler is fond of distributed programming, but he hates blind object remoting. For a good read, see:

    http://www.sdmagazine.com/documents/s=7897/sdm0304a/sdm0304a.htm?temp=src8Ub4XpT

    What Martin says is:
    Transparency is valuable, but while many things can be made transparent in distributed objects, performance isn’t usually one of them. Although our prototypical architect was distributing objects the way he was for performance reasons, in fact, his design will usually cripple performance, make the system much harder to build and deploy—or both.

    That is why modern architectures stress locality, even within distributed environments. Take Coherence as an example: The whole point of coherent clustered caching, shared memory, data grids, information fabrics, etc. is that the objects end up being used where thy are needed, and not glued into some arbitrary remote server. See:

    http://wiki.tangosol.com/display/COH31UG/Cluster+your+objects+and+your+data
    Performance is the inverse of latency, and latency is the measurement of how long something takes to complete. If increasing performance is the goal, then getting rid of anything that has any latency is the solution. Obviously, it is impossible to get rid of all latencies, since the High Availability and reliability aspects of an application are counting on the underlying infrastructure, such as Coherence, to maintain reliable up-to-date back-ups of important information, which means that some operations (such as data modifications and pessimistic transactions) have unavoidable latencies. On the other hand, every remaining operation that could possibly have any latency needs to be targeted for elimination [..]

    Remote procedure calls, or any distributed work for that matter, introduce latency.
    Which incidently leads me to the 8 fallicy's of distributed programming:

    http://today.java.net/jag/Fallacies.html

    So in short distributed computing is difficult.

    You're mixing your metaphors at this point. While integration across multiple applications (even if they pretend to be a single application) will sustain many of the eight fallacies, an application that is running in a distributed environment (e.g. scale-out infrastructure) quite often disproves these points. For example:

    1. The network is reliable

    Networks are not inherently unreliable, any more than a CPU or its RAM are unreliable. I've done work with several major exchanges, for example, and they all rely on the network being reliable. Sure, packets get lost and NICs die and routers lock up and servers crash and switches reboot and cabling gets disconnected, but those are localizable events. The network itself can certainly be reliable, despite failures within the network.

    (By the way, that's a core principle behind grid.)
    Asynchronous messaging makes it easier, but doesn't work that well for interactive applications.

    All of our messaging is asynchronous, and most of the applications built on top of Coherence are "interactive". Just because the messaging is async doesn't mean that the programming model has to be.

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  365. distributed applications[ Go to top ]

    Asynchronous messaging makes it easier, but doesn't work that well for interactive applications.
    All of our messaging is asynchronous, and most of the applications built on top of Coherence are "interactive". Just because the messaging is async doesn't mean that the programming model has to be.Agreed. Good post. I've used messaging systems on a couple of occasions and they really worked well. People just tend not to use them. Not sure why (I assumed that it was due to latency).

    Paul
  366. distributed applications[ Go to top ]

    Agreed. Good post. I've used messaging systems on a couple of occasions and they really worked well. People just tend not to use them. Not sure why (I assumed that it was due to latency).

    Until MDBs came out, JMS was a PITA for J2EE apps.

    I don't think it's about latency. P2P implementations of JMS make the latency almost indistinguishable from raw sockets.

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  367. distributed applications[ Go to top ]

    I've used messaging systems on a couple of occasions and they really worked well. People just tend not to use them. Not sure why (I assumed that it was due to latency).Paul
    It is because most people think "database" and "user interface". Or "batch process" and "database". And that is all they need, or so they think. I try to introduce JMS, JINI, GRID, Coherence, etc. And I get:

    JMS - isn't that for plaform to platform?
    JINI - isn't that dead/for toasters?
    Grid - isn't that for massive computations?
    Distributed Caching - We already have a db.
  368. 4. If your customer just want a presentation on top of a database with minimal business logic.
    Doesn't this violate the DRY principle? Or is it really RO (repeating others) so it is ok?
    Incidently all this talk about industrial strength "enterprise wide" applications. Where are they?
    Part of it is because the tool (EJB 1-2) didn't fully fit the job (It worked for some things). I think the main reason is because people continue to avoid OO/componetizing on a larger scale and do things like "putting a web front end on a database". They continue to build bottom up or top down. Not middle out. It's not buildings or clouds or lightening we are making. :)

    Yes, but to achieve real code reuse, you're going to want to define a real domain model that you can build your services against. This allows for reuse of those models and services enterprise wide. The fact that more enterprises aren't doing this is a BAD thing, not something we should hold up as an example of why it's not needed.
  369. 4. If your customer just want a presentation on top of a database with minimal business logic.
    Doesn't this violate the DRY principle? Or is it really RO (repeating others) so it is ok?
    Incidently all this talk about industrial strength "enterprise wide" applications. Where are they?
    Part of it is because the tool (EJB 1-2) didn't fully fit the job (It worked for some things). I think the main reason is because people continue to avoid OO/componetizing on a larger scale and do things like "putting a web front end on a database". They continue to build bottom up or top down. Not middle out. It's not buildings or clouds or lightening we are making. :)
    Yes, but to achieve real code reuse, you're going to want to define a real domain model that you can build your services against. This allows for reuse of those models and services enterprise wide. The fact that more enterprises aren't doing this is a BAD thing, not something we should hold up as an example of why it's not needed.
    I think you are agreeing with me and adding to it. Anyway, what you said is what I was trying to convey.
  370. It makes extensive use of metaprogramming and late-binding to faciliate the RoR DRY principle.

    Indeed, it is merely a RoR approach to DRY, and not the only approach to DRY. I use DRY because I define the data model in terms of classes, and let my ORM build the schema from these.
    Take a look at the ActiveRecord design in Rails and imagine an ActiveService component that did the same thing for WSDL/SOAP services that ActiveRecord does for SQL databases.So again in the right hands RoR would be much more productive for these types of applications too, when compared to say BEA Weblogic/Hibernate.Take a look for yourselves - and you will see that what I and others are saying holds water.Paul.

    I can indeed imagine what might result: Software that is extremely fragile, and could break in unexpected ways as soon as the service changes - you can't do everything dynamically, and as soon as you explicitly name a field or column, that part of the code can break when the data changes. And you don't have the advantage of compile-time checking to find such uses.

    There are (more stable) approaches to mapping objects to such services - this has been done by Xcalia using JDO, as was described recently on this site.
  371. Well you definately can't build Rails using Java. Have you taken a look at the ActiveRecord design? It makes extensive use of metaprogramming and late-binding to faciliate the RoR DRY principle. Java just doesn't have a meta model (MetaClass) and it is static langauge so everything must be defined at compile time, no late binding (well not much).

    You can't, huh? From what I've read about ActiveRecord, I can't say as I really WANT it. I use a real ORM and have a real domain model, upon which I can build reusable services. As for the power of dynamic languages and meta programming... In WebWork we've got our QuickStart utility which allows you to run your webapp against your sources and it will automatically reload the classes as you edit them. We're still working out some kinks with some frameworks which hold onto class references and make class reloading difficult, but it's a very promising direction so far. For the things which can be reloaded (for instance, your WebWork actions by-and-large are reloadable) you can just make your edits and refresh the page to see the changes, just like a dynamic language, but with the added bonus of static type checking and a real deployment environment.
    Incidently all this talk about industrial strength "enterprise wide" applications. Where are they? I've been building J2EE apps since 1997 and I've still yet to see true enterprise components (actually I have on a couple of occasions, but both of those examples used BEA Tuxedo (C/C++) messaging as a backbone).After all the promises from EJB1.0 to today SOAP and SOA are now being touted as the "ideal" mechanism for enterprise wide business services distribution. Let's assume that this is true for a moment and re-consider RoR constraint 4 above. Take a look at the ActiveRecord design in Rails and imagine an ActiveService component that did the same thing for WSDL/SOAP services that ActiveRecord does for SQL databases.So again in the right hands RoR would be much more productive for these types of applications too, when compared to say BEA Weblogic/Hibernate.Take a look for yourselves - and you will see that what I and others are saying holds water.Paul.

    You don't have to be using EJBs to achieve code reuse or service reuse. I also agree with the other poster that you don't want to tightly couple your code to the service schema the way ActiveRecord tightly couples you to the database schema. You are potentially not in control of the schema coming from the service, so don't set yourself up for unmanageable breakages.
  372. Now close your eyes, relax and imagine yourself beeing aware of the advantages of Ruby+RoR for a specific set of usecases, knowing that you do the same job in a cleaner way, cleaner than C++ and Java. Now get to a poppular Java Community such as therserverside and try to save their souls.........is this a déjá vu ?cheers,Andreas
    This might almost be compelling, if it weren't for 2 things:1) You could replace Ruby above with Python, Smalltalk, Lisp, etc. and it would be just as valid, and yet just as unlikely.2) Ruby's been around LONGER than Java!!!! It never caught on before. Is RoR really that incredible that it can make or break the whole language and platform? I think not.
    3. Most of the questions in comparing Java to C can be answered. (As opposed Ruby to Java which we get "I'm Stewart. Look what I can do!")
  373. Ruby is older than Java[ Go to top ]

    It is true, Ruby is older than Java. But it remained invisible for non-Japanese speaking guys like I assume most of us until a few years ago. Someone needed to translate the documentation and transfer it across the language barrier.
    That is the reasone why Ruby did not pick up earlier. But also the reason why it has already been quite mature when it appeared to European and American software landscape.
  374. Not sure that is true[ Go to top ]

    It is true, Ruby is older than Java. But it remained invisible for non-Japanese speaking guys like I assume most of us until a few years ago. Someone needed to translate the documentation and transfer it across the language barrier.

    That is the reasone why Ruby did not pick up earlier.

    But also the reason why it has already been quite mature when it appeared to European and American software landscape.

    Within the AI community, Ruby was fairly hot in 2K-2002. Just because the business market was oblivious to Ruby, doesn't necessarily mean documentation was the reason for the slow growth of Ruby. It probably is a significant reason, but I'm guessing the reasons go beyond that.

    peter
  375. C++[ Go to top ]

    I am still persuaded that C++ is indeed a valid choice if performance matters. I can very well imagine that Java can do solving of partial differential equations or other calculation intensive stuff as fast as C++. And we have to remember that in many application the time is mostly spent waiting for Oracle (or whatever DB-product). Also C++ is more dangerous, you can mess up more easily and this can be in terms of performance, not only in terms of stability.

    If it is well done and if you can't say the database or intensive numeric calculations are eating most of the time, then there can be a valid argument that C++ brings you closer to the system and make use of Linux/Unix features to get you job done with higher performance. A decent compiler with the right compiler options should off course help a lot.

    Also I have to point out that operator-overloading for numeric types is really missing in Java, at least lessening quite a bit of the pain of having to downgrade to C++...

    As always, use the right tool for the right purpose. If Ruby (or whatever is preferable in terms of development productivity) does not provide the functionality of the performance that is needed, it might be worth evaluating which parts (could be all...) need to be written in a system programming language and which one it should be. It could be C++, but it could also be Java. Or even C. I would discourage writing the whole app in C++, unless there are good reasons for that.
  376. adaptability/layering[ Go to top ]


    The true strength of Java is it adapts to changing conditions. Ten years from now, it will still be called Java, but it may be unrecognizable compared to today.


    Funny. This reminds me of a Fortran programmer who once told me this "I don't know what language we will be programming in in 10 years time but I am sure it will be called Fortran".

    Nevertheless, I tend to agree with this one. Unlike Fortran, java is still a really adaptive and as long as it keeps on being adaptive, people will not easily switch.

    Also, just try reimplementing all the APIs in another language. Undoable. If java ever fades out, then the chance is bigger that something else will be based on top of it instead of replacing it. In the end, the JVM itself is written in C/C++ isn't it? So Java also didn't replace C. It is just another layer on top of it.

    Cheers
      Erik
  377. We'll see...[ Go to top ]

    Ruby/RoR looks interesting but, as many EJB developers will tell you, early adoption may not necessarily be a good thing. Our plan is to wait until Ruby2/Rite is released (JIT VM should help with the performance), tools and libraries catch up with Java's, better adoption is achieved and the hype settles down. Then we'll see how (or if) Ruby can help solve our problems better.

    Still, I think we'll hear a lot of good things about Ruby in the coming years.

    --
    Igor Zavialov
    Factoreal Financial Data and Technical Analysis solutions.
  378. Rails[ Go to top ]

    Since I've released my XX Frameork for Java, I've been reseaching competing frameworks. One in particular caught my mind, prior to reading the Bruce Tate article. That of course in Ruby on Rails.

    I, for one, am planning to use a lot of the ideas in Rails, particularly convention of configuration. My java framework was developed in implementing commercial applications over several years and therefore pre rails, but lots of the goals (CRUD in particular) achieves things similar to rails, thought in a different manner. I wonder if I wouldn't have switched to rails earlier if given the option. Probably not completely, since I still don't like the page/scripting approach to views. Also, the imaturity of IDE's and compiler tools is also a current issue, but that may be addressed over time.

    I can't comment on the suitability of rails for all tasks, and certainly there are many tasks that it is not yet suitable for, but my business focuses on the 80% of applications that rails might work for. I'll be checking it out.

    I also agree that the time benchmarks of Java versus Rails in the article, 4 months versus 6 days need further explanation. Apples to Apples?


    David Moskowitz
    http://www.xxframework.org