Java's Biggest Long-Term Problem

Discussions

News: Java's Biggest Long-Term Problem

  1. Java's Biggest Long-Term Problem (43 messages)

    Java's biggest long-term problem is that it is not the technology of choice for entrepreneurs. Specifically, entrepreneurs have greater incentives to choose simpler and more inexpensive technologies like PHP, Ruby on Rails, and Python. Java was very entrepreneurial 10+ years ago when it came on the technology scene because it opened new doors for programmers. Since that time, Java has expanded and matured into the technology of choice for many enterprises (i.e., medium to large organizations). In an attempt to compete with Microsoft for large enterprise clients, Sun has put more emphasis on JSRs that focus on solving enterprise problems like SOA, object relational mapping, and JavaServer Faces. Unfortunately, the process of serving enterprises has made Java larger and more complex and, thus, has created more barriers to entry for technology entrepreneurs. Last week, I went into more detail regarding Java's barriers to entry for entrepreneurs in my post Java vs. Ruby on Rails. Read the rest here: http://www.pardontheinformation.com/2008/09/javas-biggest-long-term-problem.html

    Threaded Messages (43)

  2. Re: Java's Biggest Long-Term Problem[ Go to top ]

    More bollocks. Did he mention that RoR runs at the fraction of the speed of a typical Java app and its scalability is the source of many performance issues? And JSF is not the greatest, but JSF/Seam is. Get over it and stop writing "Java will be dead" blog entries. And shame to TSS for picking up this sort of misinforming posts and putting it on the front side. Is your .Net editor in charge of TSS again?
  3. I agree with Jacek's comments. Other point is that most enterprises don't give a shit about tech, they just want to earn the most, wether in Java, Ruby, COBOL or whatsoever. If it's easier to recruit Java consultants for the lowest salary, and as a bonus the project takes longer (thus meaning companies can charge more), better! There will always be some consulting company willing to do Java as long as there are other companies that requires the maintenance of some obscure Java project and pays good money. Now if you want to discuss the 'technical' merits, Java and Ruby are complimentary. Ruby is great for green-field and quick dev, while Java excels in providing infrastructure. Grails is a good example of this (dynamic/static balance), since it leverages nice libs like Spring, Quartz, Sitemesh, Hibernate, etc.
  4. And I didn't even go into the ludicrous statement is that Java's biggest issue is the lack of a cloud computing platform (haven't people done that on Amazon's already?) For all the buzz about clouds, I have yet to see one *real* app using it...in the end, when your $$$ is on the line, you want to be in control of your own infrastructure and not be stuck on a support hotline wondering why your site has been off for the last few hours...
  5. I don't necessarily agree with the post, Jacek, but I do like questioning conventional wisdom.
  6. Re: Java's Biggest Long-Term Problem[ Go to top ]

    I don't necessarily agree with the post, Jacek, but I do like questioning conventional wisdom.
    Yes that is good. But what is he questioning? Java is not the technology of choice for entrepreneurs - Well, I guess I and many others are not entrepreneurs. Can I build a plugin desktop/browser/server application in PHP or Ruby today? Java needs cheap/scalable hosting - as someone said on his blog, try googling. If hosting costs are cutting into your profit then you probably need to dump the product or learn to bill a little better. Sun needs to Pick and endorse a Web framework - They have. And who cares. Picking one framework is bad because not every web site/web app has the same needs.
  7. Re: Java's Biggest Long-Term Problem[ Go to top ]

    I think Java's biggest problem is people posting relentlessly on various blogs, forums and developer zones that Java has this or that specific problem. No offense to the poster here, who is not really complaining about the technology itself, but how companies balance their perception of Enterprise Java with their objectives. After all, I agree with him, we did my company's first website in PHP, which was a mistake, as we found it very hard to make it to evolve correctly, and migrated to JSF after 4 years. Believe me, it's like seeing the light after a tunnel! Well, over the whole year, I have seen, while reading Java-related tech news, an increasing number of people trying to proove this or that other language or feature is "solving the whole thing". Most of the time, these people have 5+ years of experience in Java and 5- hours of experience with the other language (when it's not a single slideware at some conference, if you see what I mean),and only focus on a specific set of functionalities. Sorry, "specific" is in no way comaparable to "whole". I would accept "it solves the whole thing" statements if these people would write a real lessons-learned article from a real-life project experience with that new technology, including build/performance/security/scalability/testing/debugging/maintenance/interfacing/etc aspepcts. In other words, it's not because there is a small cloud in the sky that it's going to rain. IT engineers should know that. Let's face it, there are galore languages and technologies, as there have always been, and they all have their advantages and flaws, their pros and cons, and indeed, for each one of them, I can find a feature that solves a specific problem in a more efficient/faster/codeless way than Java. But the contrary is true as well. These comments can be useful though, as they can help workgroups or inidividuals into creatinng or improving frameworks that would make Java even better. Everytime one guy writes an article about how cool this other technology is compared to Java, I think he doesn't realize Companies' architects and managers will also read their statement and tend to believe, day after day, that Java is not that cool after all, that its community is divided, and will not support it anymore. Yes gentlemen, there are an immense majority of projects using Java technologies that go much beyond the scope of university teamwork and startups ! Well, my perception is I haven't found a single given problem that Java cannot solve. And I have to say I wasn't a Java enthusiast in the first place. I have never seen such an active scene of developers and vendors commited into making its ecosystem to evolve, taking into account so many aspects of sotfware engineering, such as backwards compatibility, performance, scalability, security, ease of use, etc. The JCP, though quite heavy, does work! Deprecating all that would benefit noone. Better capitalize on what was built until now and show Java's global advantages rather than its small flaws.
  8. Re: Java's Biggest Long-Term Problem[ Go to top ]

    Quote: "Well, my perception is I haven't found a single given problem that Java cannot solve." That's probably the single most important comment I've heard regarding Java. :-)

  9. My way of looking at this post is just about Sun and JCP , forget about frameworks part, I think they are the ones, which kept Java alive all this time. Almost every enterprise project uses one or more Apache/Codehaus projects in them. I know their are few alternative solutions in Apache AXIS2 / CXF for my questions, but tell me why should I use those when I can use JAX-WS which is JCP recommended. Java can solve every problem. I do believe it, but its too slow at picking up the changes and enhancements in the enterprise world (may be due to JCP). In SOA/RIA space, we can clearly see, we are no where closer to reality. Simple example look at the java web services certification http://www.sun.com/training/catalog/courses/CX-310-220.xml its still covering JAX-RPC, which is not recommended at all (WS-I), I think it was never updated in the last 3 years. Even I had written a supporting comment when people use to say Java is Dead!,but now i think its time for Sun to realize these facts and work on them. I still believe Sun can make it back, hope that happens sooner. - Siva Prasanna Kumar
  10. +1 Also, one shouldn't underestimate the productivity benefits Java using modern IDEs and frameworks ie. type ahead, autocomplete, refactoring, With Hibernate and Spring (and other similar frameworks), java has gotten to a very healthy space in recent years. It does suffer a little by not having a dominant web framework (It certainly has plenty of very good ones, but no dominant one at present), but with the growing popularity of GWT and Wicket we might see one emerging very soon. Java's going nowhere in a hurry and is still a very good choice for a large number of greenfield projects
  11. Who carse about being Cool?[ Go to top ]

    This drivel about being "cool" is total non-sense. If you choose a platform, choose it because it solves the problem. having worked in large companies the last 7 years, it's not about "cool". It's about having mature products, frameworks, resources and trained engineers. It doesn't matter how "cool" a framework or language is, if you have to spend 80% of the time working around the limitations. Worse yet, if you choose a platform that can't scale to meet the business needs, that "cool-ness" is not a huge mistake. Having said that, JSP and java aren't harder to use than PHP or ROR. What's hard is when the executives dictate "we only use EJB" and having to suffer through it when the project doesn't need it. Blaming java platform because stupid managers make decisions that don't make sense is pointless. They don't read TSS and don't care what developers think to begin with. If they did, they wouldn't make blanket decisions on technology when they have no understanding of development. If you really want to be productive, go educate execs and figure out how to make software development more sane.
  12. There is a long history of people believing that simplified interpreted/scripting languages and app dev frameworks will supplant mainstream curly bracket languages. They pop every decade or so. Remember 4GLs in the 80's? Despite the complexity of C/C++ (remember all those header files, deep copy constructors, pass by value or reference decisions, heap management problems etc) did 4GL's kill C and C++? No they did not. IMO the reasons are both cultural and entrepreneurial: programmers like curly bracket languages descended from C for some reason (which is why most people code in C++, Java or C# today) and you can't build an innovative new product out of a set of predefined building blocks (nobody would dream of writing an IDE, a browser, a database or an application server in a scripting language, and not just because of performance issues). The reason Java made such an impact against C++ is because of one crucial step innovation: the virtual machine. This gave us operating system agnosticism and automatic memory management at the cost of some performance, tricksy pointer arithmetic, multiple inheritance and a few useful constructs like template classes and enums (now thankfully rectified). For many people this is a trade worth making. For others it is not, so C++ is still used, say, where raw performance is vital. The likes of Python and Ruby will always have their niches, but they will never kill Java. It will take a step wise technical tour de force innovation like the java virtual machine or the formalizing of abstract data type and information hiding techniques from C into the formal OO constructs of C++ to do that. It might come from some significant development in AI, for example in Natural Language Processing, or maybe from adoption of a new theory of process such as pi-calculus. But it won't come from attempts to "simplify" something that can only be as simple as possible but no simpler. So if this happens what might the new language look like? Well, recall that Nicholas Wirth, in response to the perceived arcane, geeky, unfriendliness of C, created Pascal and then Modula 2. Did it kill C? No - as I say for some reason people just like curly brackets and semi-colons. So I would wager a tidy sum that Java's replacement (and there surely will be one) will look to us Java people today very like Java did to C++ programmers a decade ago at first glance: just like C++ without the nasty bits and a bundle of cool new features to boot. They better not forget about enum's though!
  13. Good comments but problem with dates[ Go to top ]

    Wirth, in response to the perceived arcane, geeky, unfriendliness of C, created Pascal and then Modula 2
    1971 Pascal released by Wirth 1972 C developed from B by Richie 1980 Modula2 released by Wirth ... but I can agree with much of what you said.
  14. Re: Java's Biggest Long-Term Problem[ Go to top ]

    Why? I don't think you can fix Java without breaking backward compatibility. If you are going to do that, why not plan a next generation of Java replacements instead? Java as a language suffers from many poor decisions made in a rush to get it to market. Serialization used to pass data (instead of what it was designed for), primitive types, immutables, etc. We cannot really "fix" it. Refactoring may buy some more time, but why not replace it instead? We can keep the JVM of course because that keeps getting better while the language becomes even less consistent and more bloated. Keeping the JVM will insure that we can keep all of our "legacy Java" applications and utilities as long as we need to. Legacy Java coders can keep their jobs and in 25 years when they are getting ready to retire, businesses can panic and pay them as consultants to keep their legacy applications running. In the meantime we can move forward and make progress. I see it as a "win-win".

  15. Especially in SOA - RIA terms, I don't see any major improvement at all, Java FX - is a Joke trust me its never going to be #1 RIA (the syntax is worse and harder to maintain) , look at Adobe Flex, just a simple plugin (flash player), which can be installed on demand (1.7 MB), look at Sun's jre even, if the a good java based RIA such as Nexaweb creates a beautiful applet for running, and if the end user has no java installed, it takes almost hours to download and install that plugin and jre (almost 143 MB!! got to be kidding) just to run a simple applet, I know they are planning big for that consumer JRE (Java Update 10??) (which was supposed to be 2MB, hope that comes up sooner, atleast their beta build is not 2MB for sure). I am not sure if they will ever be able to compete in Web 2.0 space (don't convince your self saying JSF and Ajax will do the trick, nope I will say atleast JSP and AJAX is better off (learning curve), I recently saw some articles about JSF Flex, whats the big deal, when flex can run on its own, why JSF??? trust me its easier to learn Adobe Flex than learning JSF :D). Look at Microsoft they cover almost complete stack WCF , WPF, WF, what more you need?? WCF seems to be way way ahead in implementing both WS-* as well as REST, I know java has Jax-WS and Jax-RS, I am sure Jax-WS is no where covering the complete WS-*, forget about *, I don't even think it covers the WS-Security (very important), in app server independent way (all examples use Netbeans/sun server, may be their is a way not clear enough). Jax-RS looks promising, I think it needs a better way of embedding in to Web Applications (I think it uses Sun's specific API for it). Any way hope something better come up real sooner else Sun will be out of market very soon, its really tough to say out so many negatives about SUN, but facts are facts!. - Siva Prasanna Kumar
  16. If TSS is any indicator[ Go to top ]

    I think this topic comes up a lot. My beliefs: Java the platform will be around quite awhile Java the language will start to become more of a legacy language except for: - inside larger IT departments which tend to lag behind industry changes (that isn't always a bad thing). - library support where structure/speed is required To the author's point, yeah I think most entrepreneurial work is probably done with quicker turnaround languages. That said if TSS is any indicator, it appears that all topics receive only 3-5 comments or, if longer, only have 3-5 participants in the discussion. Is this an indicator of the java community moving elsewhere?
  17. Re: If TSS is any indicator[ Go to top ]

    "Is this an indicator of the java community moving elsewhere? Maybe they are too busy writing java apps? Maybe they have moved on? Maybe they just have moved to another discussion board? I can still see loads of java projects out there. When it comes to (end user) product development the choice is usually .NET and be bound to windows or Java and be platform independent. All the other technologies might come into play for certain apects of the product but never as the leading technology. When it comes to projects there is often more choice regarding technology (unless the customer has certain preferences).
  18. Again...[ Go to top ]

    ...the same mantra. I am fairly sure that Java will be around for a LONG while. The reason is simply its extremely broad library. There is nothing even remotely available for most other environments, save those that run on top of the JVM and of course on the Microsoft stack. And it is very unlikely that something similar will emerge in the mid term even with massive financial support. The "enterpreneurial factor" comes in on the level of frameworks rather than the level of the language anyway. And there are frameworks available for Java that give about the same turnaround that you get with Rails or Grails. So why would you use two languages instead of one? It's just moronic. You did not learn a bit of emacs and a bit of vi and use them both a little bit - you learned one and learned it well. Much the same with languages.
  19. ... it's that the post just misses the mark. It gets negative comments in the blog, it gets negative comments on JavaRanch and it gets negative comments here. There'a a pattern, and that I think is what Jacek is getting at, and I agree with that opinion.
  20. Re: Java's Biggest Long-Term Problem[ Go to top ]

    I think the main competition to Java is C# and the .Net framework. Ruby and Python are fine and all, but I think its C# where the majority of ISVs (enterpreneurs!) are heading. I do think first Class support for a dynamic language on the JVM can really silence Java ranting, and will also be welcomed, dynamic language are seriously more fun and exciting to use. Using groovy as a drop in replacement for Java would be amazing! I wish that all Java framework maker look into this
  21. Re: Java's Biggest Long-Term Problem[ Go to top ]

    I think the main competition to Java is C#
    I'd agree if you mean "greatest number of people using it".
    but I think its C# where the majority of ISVs (enterpreneurs!) are heading.
    That threat has come and gone. I've started with .Net on a few projects and kick myself for not just starting with Java. Sometimes I want to kick others because I didn't have a choice.
  22. Re: Java's Biggest Long-Term Problem[ Go to top ]

    >Using groovy as a drop in replacement for Java would be amazing! I wish that all Java framework maker look into this
    Groovy as drop in replacement has a lots of merits, it simply adds the syntax constructs most missing to java (aka closures, refelection in the language core, real properties, and real inline string templates (a feature java really needs) But the downfall of all this is that you get a huge speed hit by applying even compiled Groovy, with huge I mean really huge. The Groovy developers themselves say there is a load of room for improvement. So adding Groovy to your language must be thought over twice, never appy it in performance critical parts of your system! All this applies probably for ruby/jruby as well.
  23. Re: Java's Biggest Long-Term Problem[ Go to top ]

    a feature java really needs (aka closures, refelection in the language core,real properties, and real inline string templates)
    Please, and I am really really not trying to flame here, why Java "really needs" that stuff, what are the business drivers behind those moves? Do we need them cause it looks nice? Do we need it because some other language has it? Do we need it because development costs with those features will be cut in X euros? If so, how come? Are we gonna introduce some additional costs in execution and maintainance phases by using those features in development phase? You people keep saying "WE NEED IT! WE NEED IT!", but why? What are business drivers behind this? Are you saying this with your 'geek-hack-at-home-hat' on (which I understand, and do myself), or you speak from business perspective? Please enlighten me. Thank you.
  24. Closures and other language features[ Go to top ]

    You people keep saying "WE NEED IT! WE NEED IT!", but why? What are business drivers behind this? Are you saying this with your 'geek-hack-at-home-hat' on (which I understand, and do myself), or you speak from business perspective?
    I'm going to bet you've never tried a language with the features mentioned. They are, pure and simple, more concise and powerful ways to write code serving a variety of purposes. This translates directly into business value because developers can write in 1 closure what it would take 10 or more lines of iterator, for, etc. loops to do. Multiply this by the scale of even a medium sized Java project, and the business value in T&M is obvious. Suggestion: take a couple hours and try writing some Ruby/Groovy/Javascript code using closures, reflection, etc. and solving simple problems, and then compare it by writing the same in Java. Trying to actually use the features is much more illustrative than reading about them online.
  25. ...
    Actually I have tried and worked with Groovy, however when comparing benefits and drawbacks pure Java wins hands down. If I got this right, you (people in general, not you personally), complain about syntax sugar, that you type less in those languages. Here is one tip for ya. Have rich pojo model where you have to implement equals in every class? Open Eclipse, go to Window/Preferences/Java/Editor/Templates/New Paste following into Pattern part, name it 'tss' for example. if ( this == ${object}) { return true; } else if (${object} == null){ return false; } else if(!(${object} instanceof ${myClass})) { return false; } final ${myClass} rhs = (${myClass}) ${object}; if(rhs.getId().equals(this.id)) { return true; } return false; Open your pojo, type tss and press Ctrl+Space+Enter. Does it really get faster than this?
  26. complain about syntax sugar, that you type less in those languages/blockquote> Well, taken to the extreme, one could argue that Java is syntactic sugar over assembler ;) You do type less in these languages, because the languages have incorporated constructs that make certain types of tasks much easier - this includes less typing, and less pointless, boilerplate code. If you haven't used .each{|item|...} or the very many similar language-level closures in a dynamic language, you can't appreciate how helpful they are, especially over the scope of large projects. Your templating example is cute, but kind of misses the point (IMO). Templating and smart usage of macros for common code definitely has a place in any language. In the particular example you cite, I have done this before in several software projects, and probably wouldn't use the exact method you describe, but that's not really relevant to the discussion about language features. Another practical example someone mentioned above was support for web services and XML. Native E4X-style support for XML (or Hpricot-style in Ruby) is a HUGE time saver when writing web service calls and other XML-heavy business code. Working with XML in a dynamic language is light-years ahead of what is possible with plain Java. Getting back to your original point, Java wins today from a business perspective not (mostly) because of language niceties, but because of the vibrant, rich, and deep software ecosystem around it. This ecosystem ensures that given almost any business problem, one can find a combination of canned tools written in Java to solve it. Solving the business problem thus becomes an exercise in plugging components together. If, in the future, such tools are available in other software stacks, you will see businesses start to more seriously consider alternatives to Java, especially when such alternatives save time and solve the problem in the same (or better) way. Until then, I agree with the folks on this thread, that Java has a long life ahead of it in the business world.
  27. Darn the lack of an edit button!
  28. Your templating example is cute, but kind of misses the point (IMO). Templating and smart usage of macros for common code definitely has a place in any language.
    Whats the point again? I fail to see sound business reasons supporting claims of anti-Java people. Yes, Java is far from perfect language we all know that, but your arguments how one is more productive in Groovy-and-a-like is false. Wanna evidence? If people could make more money (or cut development spendings) with Groovy they would use it.
    If, in the future, such tools are available in other software stacks, you will see businesses start to more seriously consider alternatives to Java, especially when such alternatives save time and solve the problem in the same (or better) way. Until then, I agree with the folks on this thread, that Java has a long life ahead of it in the business world.
    Of course new technologies will come in the future, Im just saying we aint there yet. And I am kind of tired of fighting against people comparing RoR with Java. RoR is not freaking 2% of what Java and JEE are. @Eric I provided template for illustration purposes.
  29. Title of this thread is misleading. Author is probably aiming only at web development. It should read: "Java's Long Term problem in generating HTML markup".
  30. Wanna evidence? If people could make more money (or cut development spendings) with Groovy they would use it.
    Not sure what your background is, but in my personal experience, there is a lot more that factors into a corporate technology strategy than simply the cost of the developers (if that's what you meant). Notwithstanding...
    Title of this thread is misleading. Author is probably aiming only at web development.
    I completely agree with this, and I think the author's point is well-taken. The fact is, it is very easy to write web applications in many modern languages/frameworks other than straight Java. These technologies have built-in facilities to make writing web-based applications easy, and to make writing common business logic easier. If they weren't better to use, people wouldn't use them.
    And I am kind of tired of fighting against people comparing RoR with Java. RoR is not freaking 2% of what Java and JEE are.
    Me too, I don't think they are directly comparable, because they are different tools that, applied appropriately, serve different purposes. Thanks for the discussion. I personally am not a Java hater, or RoR lover - I have used both quite extensively and believe more in "the right tool for the right job". My concern is that the Java community is very often closed-minded about non-Java solutions, even if those solutions may be more applicable for the task at hand. Not recognizing a problem exists isn't the same as there not being a problem.
  31. there is a lot more that factors into a corporate technology strategy than simply the cost of the developers
    Agreed. I have already mentioned in previous posts in this thread that RoR-and-a-like supporters are not taking into consideration potential problems that could occur in runtime/maintainance phases of project life cycle. What are debugging/issue-solving costs associated with languages not static in nature? Is potential loss from latters greater than benefit of 'less-typing' (though I do not believe there is less typing).
    The fact is, it is very easy to write web applications in many modern languages/frameworks other than straight Java. These technologies have built-in facilities to make writing web-based applications easy, and to make writing common business logic easier. If they weren't better to use, people wouldn't use them.
    You stand correct.
  32. Re: Closures and other language features[ Go to top ]

    ...


    Actually I have tried and worked with Groovy, however when comparing benefits and drawbacks pure Java wins hands down.

    If I got this right, you (people in general, not you personally), complain about syntax sugar, that you type less in those languages.

    Here is one tip for ya.

    Have rich pojo model where you have to implement equals in every class?

    Open Eclipse, go to Window/Preferences/Java/Editor/Templates/New

    Paste following into Pattern part, name it 'tss' for example.

    if ( this == ${object}) {
    return true;
    } else if (${object} == null){
    return false;
    }
    else if(!(${object} instanceof ${myClass})) {
    return false;
    }
    final ${myClass} rhs = (${myClass}) ${object};
    if(rhs.getId().equals(this.id)) {
    return true;
    }
    return false;

    Open your pojo, type tss and press Ctrl+Space+Enter.

    Does it really get faster than this?
    I don't know, that seems like a lot of code duplication to me. You can also automatically create getters and setters with your ide but it still clutters up you class with cookie cutter code. With groovy you can just access the attributes directly and a getter would get called automagically if it is provided.
  33. Re: Java's Biggest Long-Term Problem[ Go to top ]

    It's funny whenever entrepreneurs are offering jobs for Java based backend development months after having started with a RoR (or sth. 'agile' else) application. It's about maintainance and development/software lifecycle which becomes more important (a bigger cost center) when the business and product/code base grows. That's where Java (and .net) plays off it's cards against these 'agile' languages. (So opening the VM for dynamic languages is the best approach to get a mix of both worlds.)
  34. Stop Already!!![ Go to top ]

    The only problems I see are the following: (1) TSS keeps posting these silly repetitive subjects about someone complaining about Java, and how Java is dead, or almost dead, etc, and making it seem as if the issues are overwhelming and systemic. Ans: Use whatever tech suits your fancy and stop the belly aching already. Simple. (2) Sun needs to hire all the Wicket developers and push Wicket into the main stream even more. JFX doesn't smell right and besides, it seems like a waste of time when you already have similar mature options with Java Applets. You're asking millions of Swing Developers to ditch their Swing skills and go learn JFX with its weird syntax. Geez, what a waste.
  35. Re: Java's Biggest Long-Term Problem[ Go to top ]

    Why every "Java in fire" article is claiming JSF? Marina Coldbeans
  36. enough already[ Go to top ]

    Can you please stop posting threads like these on main TSS page? I am really having less and less incentive to visit TSS. I thought TSS was for developers who use Java to make money and have fun at the same time where they can see posts about new technologies and tools. 99% of all anti-Java threads/blogs are made not because someone really cares how to improve Java itself, but it is about blog traffic and being 'known' on the internet. You are not Hani, and now gtfo my TSS.
  37. Re: Java's Biggest Long-Term Problem[ Go to top ]

    Java is not going to go anywhere in a hurry! Yes, there are things that people don't like about Java. It's missing some features that other languages have, and it's not "exciting", but it's still the best tool for the job. The fact of the matter is that until the reason to move away from Java is becomes hugely compelling and irresistible, it's still going to be the mainstream choice. IMO the things which will need to happen before this can take place are: - new language X will need IDE support at least on a par with Java. That wouldn't happen until at least one of the big boys (Oracle, Sun, etc.) through considerable weight being it. - new language X will need library support which rivals Java. Can't see that happening any time soon. - the environment for language X will need to prove itself massively advantageous vs Java in some respect to do with scalability, productivity, etc. RoR makes such claims for productivity, Erlang for scalability. I've dabbled with Grails (even developing a feature which is part of the core code base), but have since gone back to Java, in spite of it's unsexiness. The problem with Java is not the language, it's the environment, which needs to be more dynamic, and hence more productive. That's the problem that projects such as Impala are targetting. Phil Zoio http://impala.googlecode.com/ - Impala dynamic modules for Spring Spring reloaded, fast and simple!
  38. Do not Compare[ Go to top ]

    Well, I think that this post is not about comparing. At some point the author of the original post might seem to pass a wrong message. I think it is not even a debate about what language is great or which one is more powerful vs more difficult. But at somepoint we must extract something useful out of the post. For example my company had to build a small database backed phone/email directory one of the co-worker made it in PHP. Only reason i can think of is that either PHP is easy or it carries illusion of being easy. Awkwardly it is other way around with Java. I won't pass any judgments here but i would say that for large percent of developers Java is either hard or it just carries the impression of being hard. Can that be the reason that person who jump starts a product or a concepts(like facebook) might start with something easy like PHP or .NET? Is that what the author wants to say when he mentions entrepreneurs?
  39. Re: Java's Biggest Long-Term Problem[ Go to top ]

    Virgin poster, so be gentle. I've seen this conversation so many times it should come as a Pattern with a UML diagram. I used to get nervous when people spoke negatively towards Java but I've learned that a good technology will outlast its detractors no matter how loud they yell. Coming primarily from the C/C++/Pascal/etc. world of yester-year I believe that Java is a much better language/technology than what came before it. So I say, relax, Java is going to be around for a long time. Not only that but remember how much those Cobol guys were making just a few years ago. People came out of retirement for that $$$. Developers start complaining when they get bored with a technology or they get frustrated trying to solve a problem. Perfectly normal. And, I agree that constructive criticism is a good thing for a technology to evolve and Java has some things that need added, overhauled, or perhaps even a complete redesign from the ground up. E.g. I was shocked to find out that generics were not added to Swing models, oy! And for persistence UI to DB we have to combine JPA and BeansBinding which don't play nice together and neither of which is a good solution, argh! And with the increasing requirements of today's apps, we have gone from "the architect" to "the architecture team" because no one person can learn all the technologies needed. To the original poster, I am curious what you mean about entrepreneurs not wanting to choose Java. Yes, there is a learning curve (is that what you mean by cost of entry?) but you have to use the appropriate technology for the task at hand. The biggest holes I see in Java stem primarily from the ever evolving web and how to get something seamless and integrated without having to learn 38 technologies. That's a biggie, when you're talking COE. I'm really curious how J6u10 is going to shake things up. It may by a flash in the pan or it could be big.
  40. Re: Java's Biggest Long-Term Problem[ Go to top ]

    Hello, it's original poster guy... One of Java's biggest strengths is the myriad of programming problems it is helps programmers to solve. However, Java's ability to solve a myriad of programming problems comes at a cost, which is an increase in complexity stemming from a myriad of choices (e.g., framework choices: web, object relation mapping, XML binding; and application server choices). In addition, upgrading from Java 4 to 5 to 6 is tangled mess because it is not that easy to figure out which web, database, and XML frameworks are compatible with the new version of Java and how that compatibility jives with application servers and how it jives between the frameworks since each framework is updated at its own pace. Further, by itself, answering the question which frameworks should I choose is time consuming. With that said, the biggest point I am trying to make is that businesses evolve from 1-3 person companies into 1000+ person companies and, specifically, that somebody in the Java market should target the 1-3 person companies so that they become 1000+ person Java enterprises as opposed to PHP, Python, .NET, or RoR 1000+ enterprises. Thus, I see a need that can be filled that would benefit the long-term growth of the Java community. Does anybody disagree with this statement: it would be good for Java if there was developer hosting environment similar to Google's App Engine? Particularly that the developer hosting environment would make key decisions regarding frameworks so that entrepreneurs could confidently embark on projects that would meet their Web 2.0 feature needs along with their needs for scalability and affordability.
  41. Re: Java's Biggest Long-Term Problem[ Go to top ]

    Particularly that the developer hosting environment would make key decisions regarding frameworks so that entrepreneurs could confidently embark on projects that would meet their Web 2.0 feature needs along with their needs for scalability and affordability.
    Seems to me, though I could be wrong, you are trying to replace skilled team/developers, which aint gonna happen. You get what you pay for.
  42. Java's Biggest Long-Term Problem is...[ Go to top ]

    Like with any other technology designed for people, Java's biggest long-term problem is ... people. The attention span of the crowds is short, crowds want more, newer, shiny or at least different. The popularity and standardization is a two-edged sword. Once Java as a technology was young and cool, results (the product) were the thing everyone cared about. Then it became widely adopted, turned into a day job and became sour. Now the process (keystrokes?) matters more. From various studies on product/business development the next iteration can either be the service one or the innovation one. I guess we are witnessing both.
  43. Re: Java's Biggest Long-Term Problem[ Go to top ]

    Like you said, If a system be developed and deployed for a enterprise, i think that you cannot just concern Java from the simpler and more inexpensive angle. the reason is that the first requiement for the system is about how secure and stable, which are external consideration rather than some subjective points, like how easy to use or how much cheater PHP than Java.
  44. permgen and heap[ Go to top ]

    at least make the sun jvm permgen issue disappear by default...