10 good reasons to look for something better than Java

Discussions

News: 10 good reasons to look for something better than Java

  1. Don't get me wrong. During my professional life I have written tons of Java code and of course I think it is a great language still. For sure it has been a great improvement from C++ and Smalltalk. But now even Java is starting to feel the weight of its 15 years. Indeed during my experience I had to face up with some mistakes, flaws and lacks in its design and specification that made my Java programmer life less pleasant. With millions of Java programmers and billions of lines of code out in the world, I am far to say that Java is going to be dead in the near future. Anyway after the rise of some JVM compatible languages (my favorite is Scala), these issues are becoming even less tolerable and I am starting thinking that it is time to slowly move away from Java (but not from the JVM). More in detail, in my opinion, the 10 most important problems of the Java language are: 1. Lack of closure: I don't think I have to explain this. Functional programming exists since decades, but in the last years they are gaining more and more interests, mostly because it allows to write naturally parallelizable programs. I partially agree with Joshua Bloch that underlined the problems of introducing them in Java as a second thought (the BGGA proposal was truly awful), but anyway their lack makes impossible to have any kind of real functional programming in Java. 2. Lack of first class function: this issue is in some way related to the former one but I believe it is even worse. The only way to achieve a similar result in Java is by using the ugly and sadly famous one-method anonymous inner classes, but it looks actually a poor solution. Even in C# has been provided a better one by the implementation of the delegate mechanism. 3. Primitive types: it should be beautiful if everything in Java was an Object, but they didn't design it in that way. That leaded to some issue, like the impossibility to have a Collection of int partially resolved in Java 5 through the autoboxing feature (see below). It also generated some confusion between passing by value and passing by reference. Indeed a primitive data type is passed to a method by value (a copy of the data type is duplicated, and passed to the function) while true objects are passed by reference. 4. Autoboxing and autounboxing: this feature has been introduced in Java 5 to overcome the problems caused by the presence of primitive types. It allows to silently convert a primitive type in the corresponding object, but often it is cause of other problems. For example an Integer can have null value, but the same doesn't apply to int, so in this case when the Integer is changed in an int the JVM can't do anything else than throw a difficult to debug NullPointerException. Moreover it is cause of other strange behavior like in the following example where it is not so easy to understand why the test variable is false: Intger a = new Integer(1024); Intger b = new Integer(1024); boolean test = a < b || a == b || a > b; 5. Lack of generics reification: generics are one of the cool features introduced with Java 5, but in order to mantain the compatibility with the older version of java they miss some important characteristic. In particular it is not possible to introspect their generic type at runtime. For example if you have a method that accepts as parameter a List<!--?--> and you pass to it a List you are not allowed to know at runtime the actual type of the generic. For the same reason you cannot create array of generics. It means that despite it looks quite natural the following statement won't compile: List[] listsOfStrings = new List[3]; 6. Unavoidable generics warnings: have you ever found yourself in the impossibility to get rid of a bothering warning about generics? If you make a large use of generics like me, I bet you did. And the fact that they felt the need to introduce a special annotation to manage this situation (@SuppressWarnings("unchecked")) is symptomatic of the dimension of this problem and, in my opinion, that generics could have been designed better. 7. Impossibility to pass a void to a method invocation: I admit that the need to pass a void to a method could look weird at a first glance. Anyway I like DSL and while implementing a special feature of my DSL library (lambdaj) I had the need to have a method with a simple signature like this: void doSomething(Object parameter) where the parameter passed to this method is the result of another method invocation done with the only purpose to register the invocation itself and execute it in the future. With my big surprise, and apparently without a good reason, since the println method returns void, I am not allowed to write something like this: doSomething(System.out.println("test")); 8. No native proxy mechanism: proxy is a very powerful and widely used pattern, but Java offers a mechanism to proxy only interfaces and not concrete classes. This is why a library that provide this feature like cglib is employed in so many main stream frameworks like Spring and Hibernate. Moreover cglib implements this feature by creating at runtime a Class that extends the proxied one, so this approach has a well known limitation in the impossibility to extend and then proxy a final Class like String. 9. Poor switch ... case statement: the switch ... case as specified in java allows to switch only on int and (starting from java 5) enum. That looks extremely few powerful especially if compared with what offered by a more modern language like Scala. 10. Checked exception: like primitive types, checked exception have been one of the original sins of Java. They oblige programmers to do one of the following two equally horrible things: fill your code with tons of poorly readable and error prone try ... catch statement where often the most meaningful thing to do is to wrap the catched exception in a runtime one and rethrow it; or blurring your API with lots of throws clause making them less flexible and extensible. The real problem here is that the only way to fix the biggest part of the issues I mentioned is to take a painful decision and define a specification of the language that drops the backward compatibility with the current one. I guess they will never do that, even if I believe it should not be extremely difficult to write a program that allows to automatically translate the old Java sources in order to make them compatible with this new hypothetic release. And in the end, this is the reason why I decided to start looking for a better JVM compatible language.

    Threaded Messages (100)

  2. I really expect such an article to make reference to solid commercial reasons why we need a better mainstream programming language, and of course didn't find any. The thing is that all of the listed problems really only have a marginal effect on overall productivity when you consider the entire development lifecycle. To be honest I could probably write 10 COMMERCIAL reasons why we don't NEED a replacement. 1) Its limitations are well understood, and in many cases are mitigated by availibility of appropriate libraries and tools. 2) There is a huge amount of exiting code to leverage. 3) The language is very amenable to static analysis and automation of refactoring. 4) Huge pool of experienced programmers to draw on. .... OK I got bored here but you get the idea ...
  3. 1) Its limitations are well understood, and in many cases are mitigated by availibility of appropriate libraries and tools.
    That doesn't seem like a very good reason. Understanding the limitations of a tool is important but doesn't make them any less limiting. Tools and libraries are intellectual overhead and eliminating the need for them would be a good thing.
    2) There is a huge amount of exiting code to leverage.
    Many new languages (including Scala) can leverage Java libraries.
    3) The language is very amenable to static analysis and automation of refactoring.
    Other static languages also have this property. It's possible they could be more amenable to static analysis. For example, Scala has a more sophisticated generics syntax and therefore Scala code can contain more static typing information than java code.
    4) Huge pool of experienced programmers to draw on.
    Your best argument here. I think that Java will remain a core language even if newer languages are used on the JVM. Neal Gafter makes a compelling argument that Java must be the common language on the JVM. Any library written on Java can be used by any JVM language that integrates well with Java. This isn't necessarily true for libraries written in other languages on the JVM. Java therefore will continue to have an important place on the JVM and will continue to need to improve but for different reasons than in the past.
  4. That doesn't seem like a very good reason. Understanding the limitations of a tool is important but doesn't make them any less limiting.
    It is a good reason, in business software engineering at least. If you understand the limitations, you can manage them. If you have something new, you don even know fully what its limitations are. Better the devil you know than the devil you don't is the reasoning here.
    Tools and libraries are intellectual overhead and eliminating the need for them would be a good thing.
    Having to know how to work them as tools and libraries, or having to know how to work them as a language features. Six of one, half-dozen of the other.
    Many new languages (including Scala) can leverage Java libraries.
    Yes... but Mario is proposing a new, backwards-incompatible language.
  5. Yes... but Mario is proposing a new, backwards-incompatible language.
    What I meant to say is that the only way in which Java could recover from its design errors and evolve is by dropping the backward compatibility. And since I am pretty sure they won't do that I will go with Scala.
  6. That doesn't seem like a very good reason. Understanding the limitations of a tool is important but doesn't make them any less limiting.


    It is a good reason, in business software engineering at least. If you understand the limitations, you can manage them. If you have something new, you don even know fully what its limitations are. Better the devil you know than the devil you don't is the reasoning here.
    If I know that I can't achieve what I want to do with a given tool, sticking with it is completely irrational. Obviously there is a risk in using a new tool but there is also a risk in not choosing a new tool. Consider what has happened to the nations that have used this line of thinking with regard to military technology. The exact logic you are using is what has kept people using COBOL. And COBOL is very stable. Its limitations are well known. Based on what I have seen, COBOL is one of the most expensive languages to develop systems in. Overall, I don't think right now is the time to jump into a new language but I am definitely watching what is going on.
  7. I don't think any one of the problems pointed out falls into an "I can't do what I want" situation. They are minor annoyances at best. Moving to another language only replaces those annoyances with others that you might not know about yet. It's a bit ridiculous to bring up COBOL as a comparison, and somewhat of a red herring. Moving to Java provided enormous benefits over the non-OO languages and tools of the past. Does functional programming provide that much of a benefit over OO programming today? Not in all cases, unfortunately. I'm sorry, but I really expected more out of this article. Frankly, none of these issues is anything more than a minor hassle, or just pointing out something the language lacks on purpose. I have no problem with moving to another language if it provides concrete benefits over Java in the same situations I'd use Java. There are already languages I'll use in situations I won't use Java. But in those situations where I do, does it really make sense to start using Scala or Haskell just because they're cooler? Or (my personal pet peeve) because they provide closures? Are closures really that freaking awesome that I have to throw out all of the available frameworks and libraries that I would normally use to put together an enterprise application? How does that discussion with a client go? "You know, I really think that writing 5 lines of code more elegantly as 2 lines from time to time is worth the risk I'm introducing into your project by leaving behind my well-tested libraries, frameworks, IDEs, and testing tools." All of this nitpicking of Java is inevitable, I suppose, but it smacks of a certain middle life crisis kind of obnoxiousness. Sure, I can understand why you might be able to point out things about your wife that bug you after 15 years of marriage. But that doesn't mean you'll look any less ridiculous cheating on her with a lesser woman. Or that you'll regret it any less after the divorce when you start to realize how banal your new partner is.
  8. Does functional programming provide that much of a benefit over OO programming today?
    With Scala you have both OOP and functional.
    does it really make sense to start using Scala or Haskell [...] because they provide closures?
    Yes! Unless you don't understand functional programming.
    Are closures really that freaking awesome that I have to throw out all of the available frameworks and libraries?
    I am tired to read that. Scala is compiled in bytecode, is 100% compatible with JVM and you don't have to throw out anything.
    How does that discussion with a client go? "You know, I really think that writing 5 lines of code more elegantly as 2 lines from time to time ...
    Programming by copy and paste is always a maintainability problem and functional programming is the best tool I know to avoid it.
    Sure, I can understand why you might be able to point out things about your wife that bug you after 15 years of marriage...
    The fact that you are comparing a programming language to your wife is symptomatic of how biased you are.
  9. Does functional programming provide that much of a benefit over OO programming today?

    With Scala you have both OOP and functional.

    does it really make sense to start using Scala or Haskell [...] because they provide closures?

    Yes! Unless you don't understand functional programming.

    Are closures really that freaking awesome that I have to throw out all of the available frameworks and libraries?

    I am tired to read that. Scala is compiled in bytecode, is 100% compatible with JVM and you don't have to throw out anything.

    How does that discussion with a client go? "You know, I really think that writing 5 lines of code more elegantly as 2 lines from time to time ...

    Programming by copy and paste is always a maintainability problem and functional programming is the best tool I know to avoid it.

    Sure, I can understand why you might be able to point out things about your wife that bug you after 15 years of marriage...

    The fact that you are comparing a programming language to your wife is symptomatic of how biased you are.
    Best post - not much to be added. But I must admit when I saw Scala first time -- after 11 years of doing Java I had VERY similar thoughts like those above - but 7 months later I am getting whole picture. And for naysaayers - who is forcing to switch ? (if you dont mind writing twice as much of code - stick with what you have -- gee not to even mention threading stuff)
  10. Does functional programming provide that much of a benefit over OO programming today?

    With Scala you have both OOP and functional.

    does it really make sense to start using Scala or Haskell [...] because they provide closures?

    Yes! Unless you don't understand functional programming.

    Are closures really that freaking awesome that I have to throw out all of the available frameworks and libraries?

    I am tired to read that. Scala is compiled in bytecode, is 100% compatible with JVM and you don't have to throw out anything.

    How does that discussion with a client go? "You know, I really think that writing 5 lines of code more elegantly as 2 lines from time to time ...

    Programming by copy and paste is always a maintainability problem and functional programming is the best tool I know to avoid it.

    Sure, I can understand why you might be able to point out things about your wife that bug you after 15 years of marriage...

    The fact that you are comparing a programming language to your wife is symptomatic of how biased you are.


    Best post - not much to be added.

    But I must admit when I saw Scala first time -- after 11 years of doing Java I had VERY similar thoughts like those above - but 7 months later I am getting whole picture. And for naysaayers - who is forcing to switch ? (if you dont mind writing twice as much of code - stick with what you have -- gee not to even mention threading stuff)
    Here-here, this is indeed an excellent reply to a mis-informed post.
  11. Agree[ Go to top ]

    I have to agree that the premise reads like you want to throw the baby out with the bath water. Probably a more realistic title would be "Things about Java that kinda annoy me, but really are not a big deal."
  12. Moving to another language only replaces those annoyances with others that you might not know about yet. It's a bit ridiculous to bring up COBOL as a comparison, and somewhat of a red herring.
    It's not a red herring. The arguments that I responded to were equally valid arguments for sticking with COBOL. In fact I've heard them used as arguments for sticking with COBOL. COBOL developers tell me that Java doesn't do anything COBOL can't do (which is strictly true) and that all languages are basically the same. Yeah, you might avoid some of the annoyances of COBOL if you use Java but there new annoyances that don't apply to COBOL (which is also true.) Just because I know my car doesn't have the most modern safety features doesn't make my car any more safe. Knowing limitations is a good thing but doesn't necessarily overwhelm the advantages of new tools.
  13. The thing is that all of the listed problems really only have a marginal effect on overall productivity when you consider the entire development lifecycle.
    +1 Well said! The world has already seen languages that tried to be all things to all people, and look where they're now (and have been for quite some time).
  14. The thing is that all of the listed problems really only have a marginal effect on overall productivity when you consider the entire development lifecycle.

    +1

    Well said! The world has already seen languages that tried to be all things to all people, and look where they're now (and have been for quite some time).
    +1 If you need such features so desperately that you would like to switch from Java, you are possibly using the wrong tools for a given task.
  15. I could probably write 10 COMMERCIAL reasons why we don't NEED a replacement.
    Does that mean that it is wrong or useless to judge a programming language under a technical point of view and considering its syntax and features? Maybe I am a bit naive, but I am really surprised of that!
    4) Huge pool of experienced programmers to draw on.
    If everybody reasoned in that way we were all programming in cobol still. Don't you think so?
  16. These were good reasons to keep Visual Basic around too.
  17. 3. Primitive types: it should be beautiful if everything in Java was an Object, but they didn't design it in that way. That leaded to some issue, like the impossibility to have a Collection of int partially resolved in Java 5 through the autoboxing feature (see below). It also generated some confusion between passing by value and passing by reference. Indeed a primitive data type is passed to a method by value (a copy of the data type is duplicated, and passed to the function) while true objects are passed by reference.
    Everything is passed by value in Java including Object references. What makes this confusing is that people have been insisting on referring to passing a reference by value as 'pass by reference' for 15 years. The distinction is subtle but anyone who knows what pass by reference means will be confused by the misuse of that term.
  18. Everything is passed by value in Java including Object references. What makes this confusing is that people have been insisting on referring to passing a reference by value as 'pass by reference' for 15 years. The distinction is subtle but anyone who knows what pass by reference means will be confused by the misuse of that term.
    James, I wish you had explained this subtle distinction for folks. A very simple but effective explanation can be found here: http://www.javaworld.com/javaworld/javaqa/2000-05/03-qa-0526-pass.html This little quirk of Java's causes a lot of problems because even though the argument's reference cannot be changed in the method, the values it contains can which can lead to side effects. New programmers'(but particularly old ones) see "pass by value" and assume that the values of the argument object's fields will not be changed when you return and they are wrong. Add immutable classes and primitives to the mix and it can really confuse someone. Offtopic: Why isn't captcha displaying on Firefox since I upgraded to 3.5?
  19. Everything is passed by value in Java including Object references. What makes this confusing is that people have been insisting on referring to passing a reference by value as 'pass by reference' for 15 years. The distinction is subtle but anyone who knows what pass by reference means will be confused by the misuse of that term.


    James,

    I wish you had explained this subtle distinction for folks.
    I've explained it at least ten gazillion times. The worst part is people will argue about it and come up with convoluted explanations like it's 'pass by reference for objects except when the object is immutable and the moon is in it's third phase and mars is in the house of Aquarius'. As a whole we should always refer to this as passing references by value. That way if someone isn't sure what that means, they have an opportunity to find out. If you call it something else that is commonly understood, they won't know to ask for clarification. P.S. Do you use NoScript turned or anything that might block scripts?
  20. Hence release of Groovy..[ Go to top ]

    Yeah, something better than Java.. I've been a Java programmer for 12+ years now, and it is lacking a lot of good to have features. Hence Groovy was born. I do think that Java is going to stay for a good while, given general acceptance patterns and mainstream product directions. We'll probably see Groovy evolve quite a bit, with other toolkits/features, but nevertheless, Java is going to stick around.
  21. Bad reasons[ Go to top ]

    The thing is that all of the listed problems really only have a marginal effect on overall productivity when you consider the entire development lifecycle./blockquote> +1 Sounds like an article written after returning from a scala presentation. Marginal examples will never justify an overall thing. 1) Personally, I could live 10 years without closures. I coded millions of lines. I felt like I neded them only ONCE. I think people talk much more about on closures than they'd use it. 2) Same thing, pointless. 3) What if you deal with streaming or manipulating graphics? Primitives may be useful according to your specific needs. 4) Well, as the spec says. Would the test succeed soemone else would complain the other way around. 5) class StringList extends ArrayList and then StringList[] lists = new StringList[3]. And you can also get the generic type at runtime with Clazz#getGenericSuperclass() and ParameterizedType#getActualTypeArguments() 6) It almost never happens if your code is well designed. It only happens if: - you use 3rd party libs that use collections w/o generics - you mess with casts, Object#clone(), Class#newInstance(), Class#forName() (and alike reflex methods). I have a 100000 lines project here, 6 unchecked found, only messy casts (jndi lookups, Class.forName...). I'll live. 7) Wow THAT is marginal. I don't think the java stack would like that. How can I explain it? Void is...void...by definition. void.class does exist though. 8) Hibernate users also know it has evil effects (equals, etc). Proxying final classes are pointless -by definition-. One calls a method on a proxy to perform an operation to change some state behind it. What do you want to change on a final class instance? 9)Very marginal all the more as if/elseif do the job perfectly. And see http://openjdk.java.net/projects/coin/ 10) Would it be all like in C#, someone else would complain the other way around. More seriously, that used to be right, but the times of SQLException's are gone. In a typical app with modern frameworks, you'll be only annoyed by IOEx and GeneralSecurityEx (and only if you work with files/streams/URL's and Crypto). As a general advice, languages are means, not ends. If one solves better a given problem at a given moment (and your customer has nothing against it), then go for it!
  22. Re: Bad reasons[ Go to top ]

    1) Personally, I could live 10 years without closures. I coded millions of lines. I felt like I neded them only ONCE. I think people talk much more about on closures than they'd use it.
    The fact that you don't need closure (probably because you don't understand them) doesn't mean that the WHOLE world doesn't need them as well.
    2) Same thing, pointless.
    Same thing ... of course is pointless for somebody who doesn't understand it. I'm curious to read your code: I bet your favorite pattern is copy and paste :)
    3) What if you deal with streaming or manipulating graphics? Primitives may be useful according to your specific needs.
    Why couldn't I do the same if they were actual objects?
    4) Well, as the spec says. Would the test succeed soemone else would complain the other way around.
    The fact that the spec says something stupid doesn't mean that it is fine that it works in that way.
    5) class StringList extends ArrayList and then StringList[] lists = new StringList[3]. And you can also get the generic type at runtime with Clazz#getGenericSuperclass() and ParameterizedType#getActualTypeArguments()
    The fact that you can find a (poor readable and horrible) workaround doesn't mean that it is fine that it works in that way.
    6) It almost never happens if your code is well designed. It only happens if:
    - you use 3rd party libs that use collections w/o generics
    - you mess with casts, Object#clone(), Class#newInstance(), Class#forName() (and alike reflex methods). I have a 100000 lines project here, 6 unchecked found, only messy casts (jndi lookups, Class.forName...). I'll live.
    I will live as well, but I could live better without it.
    7) Wow THAT is marginal. I don't think the java stack would like that. How can I explain it? Void is...void...by definition. void.class does exist though.
    I agree, it is marginal. But there is no explanation for such a stupid thing unless you don't consider "void is void" a good explanation.
    8) Hibernate users also know it has evil effects (equals, etc). Proxying final classes are pointless -by definition-. One calls a method on a proxy to perform an operation to change some state behind it. What do you want to change on a final class instance?
    If it is so evil and you are coherent, I suppose you don't use any framework that uses this pattern, isn't it? Unfortunately maybe the 90% of the Java programmers use at least one of them. Once again the fact that you don't need (or don't know how to use) something must mean that the WHOLE world don't need it. In the end I don't want to change a final class but just intercept a method called on it. But of course you don't understand the proxy pattern as well.
    9)Very marginal all the more as if/elseif do the job perfectly. And see http://openjdk.java.net/projects/coin/
    The only marginal thing here is how it is designed and implemented in Java. Check the Scala case classes to understand what I mean.
    10) Would it be all like in C#, someone else would complain the other way around. More seriously, that used to be right, but the times of SQLException's are gone. In a typical app with modern frameworks, you'll be only annoyed by IOEx and GeneralSecurityEx (and only if you work with files/streams/URL's and Crypto).
    Checked exception oblige you to deal with them at ANY level of your stack even if you don't have meaningful to do at a given level.
  23. You propose to migrate to another lanuage?. My choice is Haskell. Its not Scala because maybe the JVM Oracle will charge lots of money to use it in the future nobody knows. But I dont agree with you. I will tell you if you are a Computer Science folk yes Java have limitations but as an Engineer you can work around Java limitations and build cool stuff check out Apache Hadoop it is pretty cool stuff there it implements mapreduce and it didnt need closures, first class fucntions or anything releated to functional programming paradigm. Java is great and always will be to build serverside and web applications. You need concurrent or parallel, check out in the libraries the concurrent package. Java is OOP, not a functional language. If you want functional, yes go with Scala or Haskell. And to remind you, all languages have flaws even Haskell or Scala have flaws. Long live Java!. PS.For the folks that worry to much about how to spell correct english, Im not a native english speaker sorry.
  24. You can work around Java limitations and build cool stuff check out Apache Hadoop it is pretty cool stuff there it implements mapreduce and it didnt need closures, first class fucntions or anything releated to functional programming paradigm.
    You could implement the mapreduce algorithm even in assembler. What should that mean? I don't understand your point.
    Java is OOP, not a functional language. If you want functional, yes go with Scala or Haskell.
    Why should I choose between OOP and functional if I can have both with Scala? :)
  25. These are not "good" reasons...but marginal ones. IMHO you can use java if it solves you problems, otherwise use other technologies. For example, if I should write a little script, I would use python (or groovy, ruby...etc...etc...), using closures and other benefits. Regards.
  26. I'm not leaving Java anytime soon and I agree with the other posters that these issues are really the least of Java's problems. However, things like checked exceptions do take their toll on developer productivity and code readability and these 100 or so "paper cuts", to borrow from the Ubuntu folks, really pushes interesting development off of Java to python, scala, and rails. Java and especially JEE has evolved far too slowly for my comfort. However, many of these 10 points are things that seem pretty easy to fix. I know they could fix checked exceptions tomorrow if they wanted to. I imagine reified generics could be fixed as well. I am personally more worried about Java losing out to PHP and Rails on the low end. Java/.NET is the first choice for serious business development, but what about low-budget sites? What about customers who want huge applications but only have the budget for a mid-sized Java app? We're constantly losing them to the wealth of existing PHP apps which are pretty easy to customize. I worry that we don't have the wealth of forum, CMS, and shopping card programs written by the open source community to allow us to get a Java application up and running quickly. I'd like Java to not just be the language of heavily customized business applications but also the language in which you can get a conventional app up and running quickly. I'd be also nice if you could build a decent modern application with core JEE alone. I am personally fatigued that so many frameworks and REQUIRED to do modern development. I think Java's biggest problems are difficult and complex to solve and revolve more around usability than the technical elegance of the language fundamentals.
  27. The problem how I see it is that Java the ecosystem have been a politic thing of the big corporations. So everything is designed in Java for projects that last years to create and years to maintain that is why you feel like that. In the other hand scripting languages are doing what Java cannot do in the short time. It can be do it with Java but as you noted, it needs modern frameworks so gets easy to deploy a small to medium app in Java. If your market is small to medium business you are better with Python, Rails or PHP but dont forget that PHP can scale to huge projects as Facebook or friendster. But me personaly I like Java not PHP and I use Java->Wicket->Ibatis for small to medium projects. It is posible to do it.
  28. The problem how I see it is that Java the ecosystem have been a politic thing of the big corporations. So everything is designed in Java for projects that last years to create and years to maintain that is why you feel like that.

    [...]

    But me personaly I like Java not PHP and I use Java->Wicket->Ibatis for small to medium projects. It is posible to do it.
    I think the first part is seen by many of us, that is why people complain about Java. However little to none people dare to start with tools like Wicket, because the do not bear the approval of some companies and boards. Use the right tools, use the small tools, use less dependency and achieve more :)
  29. The grass is always greener...[ Go to top ]

    I recently left Java development to lead development of a Rails team at a small company. So far I don't see that the language features of Java and Ruby matter much in terms of my development productivity. Each language, and its encompassing development tools, frameworks, etc. provide different productivity benefits. What I have noticed is that expectations are quite different about what constitutes good programming in these different camps. In the Ruby world, the emphasis seems to be on "enough to work well", whereas in Java, which is dominated by enterprise computing, the emphasis is on "the right way to build it". Consequently, your average Java project can't even get off the ground without logging infrastructure, an exception handling strategy, an IoC container, an ORM library, build scripts, XML-to-object binding libraries, test infrastructure... and on and on. This pain is self-inflicted and not always necessary. Recently I've been laying a lot of this aside in my Java development and -- what would you know -- simple Java is simple for simple projects. Conversely, as our Rails applications get larger and more complicated at work, they are taking up about the same amount of effort as if we had used Java. The pain points are different, but they are there. The big lesson for me is that Java needs to allow development projects to start small, and grow as appropriate. I think there have been improvements in this area in recent years. Personally, I'd be happy to return to Java-based development at this point.
  30. +1 Great comment!!. Yes with Java it could be used from small projects to up. As I said Wicket with Ibatis is very easy to start small web apps with it using Java.
  31. Re: The grass is always greener...[ Go to top ]

    I recently left Java development to lead development of a Rails team at a small company. So far I don't see that the language features of Java and Ruby matter much in terms of my development productivity. Each language, and its encompassing development tools, frameworks, etc. provide different productivity benefits.

    What I have noticed is that expectations are quite different about what constitutes good programming in these different camps. In the Ruby world, the emphasis seems to be on "enough to work well", whereas in Java, which is dominated by enterprise computing, the emphasis is on "the right way to build it". Consequently, your average Java project can't even get off the ground without logging infrastructure, an exception handling strategy, an IoC container, an ORM library, build scripts, XML-to-object binding libraries, test infrastructure... and on and on. This pain is self-inflicted and not always necessary.

    Recently I've been laying a lot of this aside in my Java development and -- what would you know -- simple Java is simple for simple projects. Conversely, as our Rails applications get larger and more complicated at work, they are taking up about the same amount of effort as if we had used Java. The pain points are different, but they are there.

    The big lesson for me is that Java needs to allow development projects to start small, and grow as appropriate. I think there have been improvements in this area in recent years. Personally, I'd be happy to return to Java-based development at this point.
    +1 Can sign under every line here... In general, how many time do we have to see someone's brain dump on "10 Most..." topic. Nothing is perfect but Java is as good as it gets for serious server-side development today. Regards, Nikita Ivanov. GridGain - Cloud Development Platform
  32. Starting small and growing easily[ Go to top ]

    The big lesson for me is that Java needs to allow development projects to start small, and grow as appropriate.
    SpringSource recently published Spring Roo in order to deliver in this area: http://www.springsource.org/roo
  33. Re: The grass is always greener...[ Go to top ]

    Consequently, your average Java project can't even get off the ground without logging infrastructure, an exception handling strategy, an IoC container, an ORM library, build scripts, XML-to-object binding libraries, test infrastructure... and on and on.
    It's interesting that you bring this up, if you don't need logging facilities, don't use it; if you don't want ORM, don't use it; if you don't want to do build script, don't do it; if you don't wanna do unit testing, don't do it. Nothing is related to Java specific. I can see you explained more on how you actually want to return to Java development, but your comments quoted above is not really related to Java.
  34. +1[ Go to top ]

    I absolutely agree. And there is no development in Java. I is/was a good language for its time, but its time is limited. It is now time to switch to something new, where the brains are. (I personally prefer Scala, but that's judgmental.) Regarding generics warnings, though. I fixed tons of them in Google code. They are almost all fixable. The problem is, to fix them, one should understand them. Programmers don't understand them, and this, I'm afraid, is not Java's fault, but programmers' fault, even with the current state of Java generics (they are broken, actually).
  35. 4. Autoboxing and autounboxing: ...
    Not really a problem. I converted thousands of lines of Java 1.4 code to Java 5, taking advantage of auto boxing/unboxing. Unexpected NPEs were very rare.
    5. Lack of generics reification: ...
    Not problematic in practice either, in my experience. Generics do have Reflection support, although not the dynamic kind you described.
    6. Unavoidable generics warnings: ...
    This happens, but it's rare (and believe me, I have worked with a decent amount of Java 5 code). (BTW, @SuppressWarnings("unchecked") is Eclipse-specific.)
    8. No native proxy mechanism: ...
    Here you are completelly wrong. Since Java 5, the "java.lang.instrument" package provides something that is much more powerful than dynamic proxies. I use it heavily.
    9. Poor switch ... case statement: ...
    This is going to be improved in JDK 1.7/Java 7, with support for strings.
    10. Checked exception: ...
    Totally wrong as well, from my experience. In a previous project, we had literally thousands of checked exceptions (one for each specific business rule), but very few places in the codebase used try ... catch. There were many "throws" clauses with several different exceptions, of course, but that was a good thing: the business rules validated by each business method are part of its contract, so it makes perfect sense to declare it in the method signature; this also helped when creating JUnit tests, since each declared exception would require a separate test. In any case, personally I would love to see Scala take over Java (the language). But it won't happen. As others said, all of these technical issues are mostly irrelevant for the decision makers. So, deal with it: the Java language is here to stay.
  36. 10. Checked exception: ...

    Totally wrong as well, from my experience. In a previous project, we had literally thousands of checked exceptions (one for each specific business rule), but very few places in the codebase used try ... catch. There were many "throws" clauses with several different exceptions, of course, but that was a good thing: the business rules validated by each business method are part of its contract, so it makes perfect sense to declare it in the method signature; this also helped when creating JUnit tests, since each declared exception would require a separate test. This is arguable. I could have a business rule that states employee ID should be unique. To implement that I might call a method to check if employee exists and return a boolean; the downside is I can't enforce a contract, and so it doesn't flow naturally into unit tests. The other way is to throw a checked exception, clever but the code isn't very readable.
  37. Scala... I knew it...[ Go to top ]

    While I agree on some points (checked exceptions and closures being number one), others seem a little weak to me... (poor switch? do you really care?) Anyway, am I the only one that instinctively thinks of scala when this kind of articles arise? Don't get me wrong, there's nothing bad at it, but it seems to me that the scala community is trying to *predate* java's one... Time to visit some C# forums to say how good is java?
  38. Often, it's not the language, that should be switched. Often it's the person typing it! To fix the "advantages" (they are not really advantages!) means, to allow developers to write more ugly code and to do things that mess up architectures and maintainability!
  39. Actually I was thinking the way how the author write the article and dispute with his comments I came to the conclusion this is just a propaganda for Scala. The same way how Ruby and Rails started sometime ago to attack the Java the language and try to wash the mind of the Java community fellows. How I see it, Scala will be another hype that just pass by. Java is here to stay and If I really need to change language as I said I will go with Haskell not to Scala I dont want the same soup over and over again. 2c.
  40. I am sorry my article sounded just like a propaganda for Scala. Honestly it was not my intention. And honestly I don't like this war of the Java party against the non-Java one. There is no party to be defended here. Only technical points of view. A programming language is just a professional tool not a faith as somebody here seem to believe. The biggest part of the people who replied to my article just misunderstood (possibly intentionally) what I meant to say. I am a Java programmer since more than a decade. I still develop in Java any given day of my professional life and I am really happy and satisfied of that. This is why also outside my working time I go on programming in Java being the owner and main developer of 2 open source projects. In the end I just wanted to point out what I don't like of Java based on my experience and signal that could be some alternatives that overcome those issues. Is that so bad? Regards Mario
  41. In the end I just wanted to point out what I don't like of Java based on my experience and signal that could be some alternatives that overcome those issues. Is that so bad?
    Most people want to have what they are doing validated. They don't want to have their assumptions questioned, even if it's for their own good. Don't take it personally. By looking at alternatives to your tools you are demonstrating a higher level of awareness than the average developer. On a side-note, don't get too excited about these new tools. It remains to be seen which if any of these new languages will gain critical mass. It's OK to look at other options and then stick to what you are doing.
  42. Totally agree! All these programming languages are the same soup! The difference between all these technologies are quite few. In this topic, however, there is a comparison between a generic set of feature of a scripting language like Scala (but it could be python, groovy, ruby) and Java. The problem is that the author is trying to compare OOP with Procedural Oriented programming. The OOP is used for medium/large project, whereas small and easy procedural languages can be useful for very small project. Did you try to write an Application Server with enterprise services in python or scala? I think it is possible, and of course some one did it, but it should be better to do it in java or .Net. But what if you wanted to make a simple program to configure a Linux OS, or communicate via HTTP/SOAP quickly with a service? Did you try to do in in Java? The better choice should be python. I think the two world are complementary, and not overlapping. Finally, a good programmer that writes good code in a project is always the right thing, and the righ tool/language to use is not so relevant.
  43. In this topic, however, there is a comparison between a generic set of feature of a scripting language like Scala (but it could be python, groovy, ruby) and Java.
    The problem is that the author is trying to compare OOP with Procedural Oriented programming.
    The OOP is used for medium/large project, whereas small and easy procedural languages can be useful for very small project.

    Did you try to write an Application Server with enterprise services in python or scala?
    Do you really know of what you are speaking about? Did you ever give a look to scala before to write this post? If you think that python and scala are similar I don't think so. Scala is a SUPERSET of Java and is compiled in bytecode. That means that you can do in Scala EVERYTHING you do in Java (and possibly more). This is a fact and is not questionable!
  44. Totally agree!
    All these programming languages are the same soup!
    The difference between all these technologies are quite few.

    In this topic, however, there is a comparison between a generic set of feature of a scripting language like Scala (but it could be python, groovy, ruby) and Java.
    The problem is that the author is trying to compare OOP with Procedural Oriented programming.

    The OOP is used for medium/large project, whereas small and easy procedural languages can be useful for very small project.
    Lot's of confusion here. Scala is not a scripting language. It's statically typed (like Java) compiled OO language that supports some functional programming features. Python is also an OO language. It's dynamically typed unlike Scala. None of these languages are procedural.
  45. Sorry but you used a vey sensionalist title for your article - had it been titled "10 reasons why I dont like programming in java" then I wouldn't even have bothered with my original reply.
  46. Sorry but you used a vey sensionalist title for your article - had it been titled "10 reasons why I dont like programming in java" then I wouldn't even have bothered with my original reply.
    I LOVE programming Java. But even Java is not perfect and there are different languages with different features (and defects) that in some cases could better fit your needs. Is it so difficult to be understood or accepted?
  47. I partially agree that this is a kind of propaganda of Scala. But Scala is really interesting language allowing to mix OOP and functional programming. In other way, try to read quite complex Scala program (like Lift or some Scala sources) and you realize that it's much harder to write such unreadable code in Java :)
  48. Scala still suffers from 4, 5, and to a lesser extent 6.
  49. Steven Boscarine : A lot of innovation comes from Java and has been ported to other languages - CMSs (the original, heavy CMS compared); Lucene; Hibernate; and semantic web libraries, but gets ported to PHP and the lighter weight runtimes because Java is a pain to admin for most people (memory issues, which are diminishing these days, but you'll see them slightly more often than you'll see random mysql/mssql connection errors). As well, most programmers don't want to bother to learn the difference between "class" and "object," and deal with classpaths. Alx Dark: simple Java for simple projects is hard when you really do have to consider threading and other issues for every project, unless you have a set of "favourite libraries" that you know the ins and outs of, but that's not really transferable. Ultimately though I think (as stated) JVM based languages will become more and more important (unless Oracle does something stupid, in which case things will become much more interesting) and Java will be the lowest common denominator language on the JVM. I'm ok with that, but I agree with others that it is lamentable there's it's less practical have lightweight hosting for easily customized, leading web applications implemented in Java (shopping cart, blog, wiki, etc), given its strengths as a strongly typed, popular language provided by multiple parties.
  50. Steven Boscarine : A lot of innovation comes from Java and has been ported to other languages - CMSs (the original, heavy CMS compared); Lucene; Hibernate; and semantic web libraries, but gets ported to PHP and the lighter weight runtimes because Java is a pain to admin for most people (memory issues, which are diminishing these days, but you'll see them slightly more often than you'll see random mysql/mssql connection errors). As well, most programmers don't want to bother to learn the difference between "class" and "object," and deal with classpaths.
    It doesn't make me feel any better that these tools get ported. Java has a lot of unnecessary hindrances to rapid coding. I actually dislike dynamic languages like Groovy and Ruby as they are very difficult to work with, due to their lack of static analysis, for any project with more than one programmer. I like it when my compiler can deterministically tell me where a method is being used, without relying on unit tests (which are unreliable). The Ubuntu folks had the right idea when identifying a list of 100 paper-cuts. Java needs to make a list of 100 things in JEE and Java that are annoying, but most experienced users have worked around. One example is checked exceptions. Why are there SO MANY checked JDBC exceptions? Maybe things were different back in 1995, but I've rarely seen anyone do anything useful with a database they couldn't connect to. The vast majority of people just throw a runtime error and exit. If it was runtime exception, we can just let it fail and not pollute our code. If we had a need to actually do something in the event of not being able connect to a database, runtime exceptions can be caught just as easily as checked ones. This is an example of something we just work around and never question and cut and paste a lot of boilerplate code to handle (when you're not using JPA, of course, which hides it for you). The same goes for file handling. Why doesn't the JDK have a library to write a file to a String? I find myself in every project going to Java Almanac to lookup the same method or using something from Apache commons to load small files to Strings for my unit tests. Why doesn't JEE have IOC that works in Tomcat (yet). If I want EJB3 IOC, why do I need a container that supports JMS? These 3 are examples of what I think of as painfully obvious paper cuts. I don't think there is anything intrinsic in Java that makes it cumbersome for small projects. I think that the Sun folks have been slow to update their language to address these minor annoyances that build up and make it unprofitable to do small projects in Java.
  51. Cloneable, Date, Calendar... anybody?
  52. But ... but I dont need ANY of those things, including generics, which were a total waste of effort in my opinion. I am not convinced there ARE any important problems for the Java language right now. The language seems to work pretty well for a most business needs. If we want to do anything, I think we should stop changing Java.
  53. It is true that java does not provide every thing for you such as talking to it and it will write the code for you but it is a complete language that is well adopted and there are not alternatives so far. We are hearing about groovy, scala ...etc but you still face similar issues and Java comes always on top. I assume that an engineer can work around some "issues" such boxing and unboxing. But suggesting that Java or C# is bad and old because of the primitives management is absurd. In the meantime, it is GOOD practice to use the language as it is intended not I wish it to be such as passing void like the author wanted.
  54. Hi, Moreover it is cause of other strange behavior like in the following example where it is not so easy to understand why the test variable is false:

    Intger a = new Integer(1024);
    Intger b = new Integer(1024);
    boolean test = a < b || a == b || a > b; i think this can be understand by any amateur who just started to learn java that it is object reference which will be holding two different address... Moreover every language has some advantage and disadvantages to use... a good developer/architect will look for tools depends on requirement not just it is done by some in some project does't mean that everyone has to follow. Since Java is not just language it is a platform on which a lot of technologies are built over the years and they are enhanced by different groups/companies to make more productive if u think just java is what we use in day to day programming i think u r very wrong since we use a whole lot of other api's like Hibernate/Spring/JSF/Struts..... etc that serve the needs to a project rather than developer. Moreover the open source communities which helps resolve a lot of issues can u tell me is the same support we get for scala through blogs/communities. Moreover the different IDE support present for java could u tell me which language enjoys this much support. Atlast, Java will always be there.......RIP scala
  55. I see something similar to this quite often. A developer finds a particular feature that he/she would like and then complains that it's not in Java. The main problem with that way of thinking, is that if it was applied for all suggestions we would pretty much have goto and line numbers in Java because someone thought that it would be a good idea. There has to be an overall goal of a language and some principals that guide what we include or not. For Java that has been to make things easier for the developer and to make it harder to do mistakes. The last part being particularly interesting for this discussion. If you look at Java compared to C++ one of the main differences was memory management. The reasoning was that for most developers the manual memory management was just a tedious task that often created memory leaks. Most people here would argue that they can handle that and that they don't create memory leaks because they "know" how to program. I won't argue with that, but I will say that on average most code is written by average programmers. Applying the same logic here Mario argues that "first class functions" would be good for Java. I disagree. The reason is simply that when a lot of average programmers are given that tool in a "general purpose" language as Java, we get the same kind of problem that we see in C# with delegates. You can read this article for the background: http://java.sun.com/docs/white/delegates.html Basically, the problem is that as the project grows large these function pointers (delegates) start to be thrown around. A function pointer is not as strict as an interface since there is no coherence between multiple functions. It in fact turns out to be somewhat of a "goto" statement for the OOP world. You end with a large project where these pointers come out of nowhere and it becomes very difficult to track the dependencies. The simple reason being that on average most of the project will be written by average programmers. Of course handled wisely it can be a very useful construct. But remember the idea, to make it hard to make mistakes. We are talking about a language able to build huge systems. I don't care about a few less lines or that it's not so pretty using interfaces, visitor pattern or whatever to do the same thing. It's about having less problems at the end, about making it hard for all your average developers to do mistakes. What you have to understand is that SUN did a lot of thinking and weighing the pros and cons about different constructs before they started out with Java. They analysed all existing languages to do away with the "problems" that hindered most developers. If the feature you want isn't something that benefits a lot of java developers, but potentially is a large risk for misuse. Then the feature doesn't belong in Java. As with delegates of first class functions. There are other problems I have with the top 10 list as well, but I'll limit this already long post to just one more. Autoboxing. The other way around to handle autoboxing is what Microsoft did with C# to try and be different. With int being a struct and no real Object type you initially couldn't define a nullable int. Now they have int? how pretty is that... Working with XML for example you had to use the nice .HasValue(). It turns out that having a seperate Integer to determine a nullable object and int as a non nullable primitive is actually a very good way to handle all of this. You could however argue that it's more luck than forward thinking by SUN. The point here is that there's A LOT more thinking needed than "I like feature X I think it's cool", because Java is to be used by so many different type of developers for different scenarios. Mario. I think that you have many valid points. But I just don't see most of them being a problem for the majority of Java programmers, also some of them may even be detrimental to the majority of developers. Best regards, Mikael
  56. I totally agree with you.
  57. are they enough?[ Go to top ]

    this can be only 10 points that java is missing,even 10 minor points, that list can not make up to the reasons to abandon java and switch to some other lang
  58. Mario you did a good job of enlisting features that Java lacks or can improve on. I think business application programmer could also take advantage of features like closures & first class functions in his code, but I feel average developers available in market place would find it difficult to understand features and would end up writing code which would be difficult to maintain and maintainability is a very major requirement in such places. Moreover, you already mentioned that to implement these features backward compatibility would have to be forefieted, which I think is very difficult to do and even if we had a tool which could convert code to this new version of Java it would be a difficult proposition, since there is a huge amount of Java code deployed in market place and it would be hard to explain this to business executives who sponsor projects. Finally, I think this may not be impossible in future, provided languages like Scala gain critical mass.
  59. closure and type inference[ Go to top ]

    Java keeps falling further and further behind C# ! Java looks like more and more the new cobol. Microsoft language work is much more living, as C# 3.0 has shown good ideas about closure and type inference. And the more I learn about those ideas, the more I want to program with C# 3.0, after more than 10 years of Java programming. One of the pbs that Java faces today is closure adoption, as closure and type inference do have relationships: to make easier closure adoption, Java would need a dose of type inference; see my post for arguments, here is one example: the closure introduction faces a dilemma,
    - if the legacy notation is reused, then closures appear to be heavy,
    - if a new notation is defined, then the language gives the feel of a certain lack of coherence. The problem is: adopting closures is one step, adopting type inference is another step, and adopting both, as the same time, while it would alleviate the closure burden, is a 2-step move that looks like too much enough for Java drivers. Well, the pb with Java is that Java looks like in maintenance mode, may be it's the reason beyond why little modifications only are planned for JDK 7. Take one example: the diamond operator (a little add) is discussed for JDK 7 inclusion, while no type inference is planned. Java drivers have enforced strong rules not to change too much. So, it looks like we need the rise of another language.
  60. Java keeps falling further and further behind C# !
    Sure it does ... but, of course, in a big corporation, we also need to run on UNIX/AIX/SOLARIS. MS weenies may hate that fact or try to pretend that any of the weak partial ports of C# are useful there ... but that is the way it is, and they aren't. I think it would be a good idea for Java not to change too much - let the tools stabilize, let people experiment with other languages.
  61. Sure it does ... but, of course, in a big corporation, we also need to run on UNIX/AIX/SOLARIS. MS weenies may hate that fact or try to pretend that any of the weak partial ports of C# are useful there ... but that is the way it is, and they aren't.
    I think this is precisely why many are looking for C# like features in Java. They know their enterprise employers or clients will not throw away their huge investments in WebSphere and the like in preference for MS infrastructure just because C# has "cool" language features (nor should they unless there's a compelling financial reason for doing so). Lambda expressions don't make you more productive, but LINQ - a technology that exists because of lamdas and no type erasure - does (101 Linq samples). Imagine being able to write JPA-QL without needing strings AND getting code completion (without having to put the whole expression on a single line - IntelliJ's good but not that good) AND compile time checking. Imagine the same syntax available for in memory collections or XML data. I don't think Java should go anywhere - it's verbose but it's not COBOL verbose, but I think it should evolve at a faster pace than at present. I for one am looking forward to JSR-277 implementation because I'm sick to death of JAR hell. I challenge anyone to find a .Net 3.5 developer (note that means the IDE supported .Net languages not just additions to C#) who believes they are not more productive now than when they were using .Net 1.0. I also think the JVM should have multiple languages that have equivalent IDE support, because there is no one language style or paradigm that is universally applicable even in a single significantly sized app.
  62. Me I was a supporter of Closures for Java but it did not happend and more bad is that there is not Java SE 7 spec, so I gave up. Also I see difficult to change the mind of 5 million of Java developers, Better adapt your self to the world because you by your self can't change it. So Accept Java how it is and If you need more syntatic sugar go with Scala, C#, Clojure, Haskell, Python or Ruby. Thats my advice to everyone and to the author and other people attemp to write this kind of articles is a waste of time. You will never change the mind of many people invested on one technology that depend their lifes, jobs or whatever.
  63. Java keeps falling further and further behind C# ! Java looks like more and more the new cobol.

    Microsoft language work is much more living, as C# 3.0 has shown good ideas about closure and type inference.
    And you should see the dynamic typing features in C# 4.0 :-)
    Java drivers have enforced strong rules not to change too much. So, it looks like we need the rise of another language.
    While it's true that the Java evolution process has leaned far more to tradition than to innovation, I think it's more a problem of said process than of the technology itself. If this community that is so proud of being innovative at creating frameworks, products, and techniques would apply the same driving force to the language itself I'm sure Java would catch up C# in a couple of years (and then they wouldn't feel at risk when things like Ruby arise :-P )
  64. The Java talibans[ Go to top ]

    I am very surprised about the posts I am reading. It looks more like a taliban forum than an IT one. I'm sure that the biggest part of the people who are replying to my article were the same (if they were already in the IT world when Java born) that loved C++ and didn't need that stupid garbage collector, since they were able to free the memory far better and faster. Isn't it? Just to reply to some absurd post I saw: - Scala is a SUPERSET of Java. - Scala is both OOP and functional. - Scala is compiled in bytecode and runs in a JVM. For this reason you can use any cool Java framework you love (Spring, Hibernate and so on) even with Scala. If you don't know of what you are speaking about (i.e. you never wrote a line of code in scala in your life), please avoid to reply to this post. Regards Mario
  65. Re: The Java talibans[ Go to top ]

    @Mario, why you prefer and insist on Scala and not in Clojure instead?, It have the same features, runs over the JVM, Its dymanic, for other bunch of people dynamic typing is heaven and integrates pretty well with Java libraries or beter one that already some people is using for web development Groovy and Grails OR I have a better one the Holy Grail of programming languages Ruby! 3 years ago everybody bet that Ruby was the Next big thing, Hilariuos. Where is Ruby at? Even there is a book from Bruce Tate called from Java to Ruby. Someone said Java is already in maintainance mode but it translates that the language is already mature for serious development, Not like Ruby that is a young language and stills improving so is not yet mature for the enterprise. I think Scala is in the same position as Ruby right now. Cobol still paying the bills to many programmers and I read in somewhere about Cobol that still every year creating 5 million of lines of code so I think Cobol is not dead yet and Java is just starting like a 20's years old, Ruby and Scala still a baby but we dont know if those babies will get to the position where is Java at. From all the comments about the 80% disagree with you. We dont need a new language!.
  66. Re: The Java talibans[ Go to top ]

    @Mario, why you prefer and insist on Scala and not in Clojure instead?, It have the same features, runs over the JVM, Its dymanic, for other bunch of people dynamic typing is heaven and integrates pretty well with Java libraries or beter one that already some people is using for web development Groovy and Grails OR I have a better one the Holy Grail of programming languages Ruby! 3 years ago everybody bet that Ruby was the Next big thing, Hilariuos. Where is Ruby at? Even there is a book from Bruce Tate called from Java to Ruby.
    Sorry ... I forgot to mention a characteristic of Scala: it is statically typed and I don't like dynamic languages. For what concern Groovy as you can read here: http://java.dzone.com/articles/scala-long-term-replacement that even its creator wrote: "I can honestly say if someone had shown me the Programming Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy."
    From all the comments about the 80% disagree with you. We dont need a new language!.
    I don't NEED a new language. But I like to experiment and I was wondering if there could be something better outside. I believe there is no golden hammer that you can use always and wherever, but you should have the widest set of tools possible in your hands in order to choose case by case the best one that fits your particular needs. Most of time it could be Java, and other times Scala, Ruby or whatever you want. Is that so crazy?
  67. I agree with most if not all the points you make about Java, but not your conclusion. I find these points tend to be irritations that you occasionally bump into, rather than obstacles that really impede your day to day progress. I love Groovy for integration and scripting tasks, and Scala apparently has solutions to all the problems you've described, and more. The big problem for me is complexity - Scala is much more complex than Java - a big leap for the average Java developer, and possibly a jump too far for most. Also, until the IDE support rivals that of say Eclipse's Java support, it will be hard to take another language really seriously for bread and butter day to day development. Phil Zoio http://impala.googlecode.com/ - Impala - reloadable dynamic modules for Spring
  68. Java is no[ Go to top ]

    improvement over C++. Only someone who doesn't understand C++ could say that.
  69. How about Smalltalk[ Go to top ]

    Heh heh.. Good old Smalltalk is becoming hot again. Take a look at Seaside and see what a breeze it is to develop websites with Smalltalk and Seaside. And maybe one could get interested in NewSpeak. It's actually old news ;)
  70. One more thing...[ Go to top ]

    Mario, you do realise that 9 out of 10 complains above are arguments why Java is obviously superior to C++? Oh wait.
  71. Re: One more thing...[ Go to top ]

    Mario, you do realise that 9 out of 10 complains above are arguments why Java is obviously superior to C++? Oh wait.
    Sorry, but to be honest I haven't understood the meaning of this sentence. Could you explain it better, possibly with a small example?
  72. Re: One more thing...[ Go to top ]

    Sarcasm, obviously. I find it ironic that 9 out of your 10 problems above are a result of Java desperately trying to improve upon C++, first by irrationally removing features, then by slowly adding them back in a half-assed way. Those problems don't exist in C++, yet you're sure Java is a "great" improvement over it.
  73. Re: One more thing...[ Go to top ]

    Sarcasm, obviously.

    I find it ironic that 9 out of your 10 problems above are a result of Java desperately trying to improve upon C++, first by irrationally removing features, then by slowly adding them back in a half-assed way. Those problems don't exist in C++, yet you're sure Java is a "great" improvement over it.
    Ah ... now I have understood. And I have to admit I agree with you. It seems when they design Java for the first time, they tried to make it dummy-proof. But doing in that way, they left out lots of good features. Indeed more or less the half of my complains are related to still missing features while the other half are caused by features that have been added in a second stage, but not in a completely satisfying way (mostly to keep the backward compatibility).
  74. Re: One more thing...[ Go to top ]

    Sarcasm, obviously.

    I find it ironic that 9 out of your 10 problems above are a result of Java desperately trying to improve upon C++, first by irrationally removing features, then by slowly adding them back in a half-assed way. Those problems don't exist in C++, yet you're sure Java is a "great" improvement over it.

    Ah ... now I have understood. And I have to admit I agree with you. It seems when they design Java for the first time, they tried to make it dummy-proof. But doing in that way, they left out lots of good features.

    Indeed more or less the half of my complains are related to still missing features while the other half are caused by features that have been added in a second stage, but not in a completely satisfying way (mostly to keep the backward compatibility).
    Cheers Mario, and sorry for the sarcasm - this is actually the first time someone on TSS agrees with that point of view (I'd stopped visiting TSS about 3 years ago when it had finally turned into an product release ticker, and just returned today out of curiosity). As a side note, I think a real attempt at improving upon C++ is the D language (http://www.digitalmars.com/d/). One can debate about the success of the attempt, but at least D didn't show the misguided contempt for C++ that Java had.
  75. Re: One more thing...[ Go to top ]

    Sarcasm, obviously.

    I find it ironic that 9 out of your 10 problems above are a result of Java desperately trying to improve upon C++, first by irrationally removing features, then by slowly adding them back in a half-assed way.

    Ah ... now I have understood. And I have to admit I agree with you. It seems when they design Java for the first time, they tried to make it dummy-proof.

    I had some experience already with C++ et al when Java came out, and I must say I am not missing the STL (for example) a single bit.

    When you are talking about the great things of C++ that are left behind, you obviously are not talking about the same language I know. Even with simple sentences such as "a = b + c" I didn't know how many methods were being called (including: overload equals, overload +, copy constructor, operator priorities), and Scala is bringing the same old ghosts back.

  76. Re: One more thing...[ Go to top ]


    I had some experience already with C++ et al when Java came out, and I must say I am not missing the STL (for example) a single bit.


    When you are talking about the great things of C++ that are left behind, you obviously are not talking about the same language I know. Even with simple sentences such as "a = b + c" I didn't know how many methods were being called (including: overload equals, overload +, copy constructor, operator priorities), and Scala is bringing the same old ghosts back.

    You're obviously not any good at reading - if you don't know how many methods are called, you haven't read the code. Also you were clearly unable to follow the simple instructions in BOLD located on the right hand side of the message composing textbox, so there's no wonder :^) Seriously though, I urge you to read this article http://www.stlport.org/resources/StepanovUSA.html as I hope it'll give you a better understanding of the (in my opinion revolutionary) ideas behind the STL.
  77. I kinda feel the same as you are right now. Java is getting boring. I'm trying learning both python and ruby. Ruby is quite fun and python though has a weird syntax but it's blazing fast. I think there are more and more ruby & python jobs in the job market too these days. So far I'm happy learning python and ruby.
  78. Java is not a good language. It lacks many nice things like overriding of operators, closures... Many languages like Python, C#, scalar even the old C++ have more features. I agree. But... Java has the most complete set of API and libraries you can think of. Ok Scala, Jython and other can use the same API in their code, nice. But java has also really good IDE integration, just think of about what Eclipse do for you... It's simply wonderfull. Just type CTRL-SHIFT-T... And instantly find your class.CTRL-O for quick outline. with the famous CTRL-1 and CTRL-SPACE you have auto completion, templates, refactoring, fast correction of many code error etc... 90% of code burden is handled by the IDE... Scala has a nice way of managing imports. So what? I never have to care of import when writing my code. The IDE take care of that. I want to rename a method/class that is used in 200 differents place of 15 projects ? Just use the refactor feature. Want to extract a method ? ALT-SHIFT-M. Want to see the implementation of that method ? CTRL-CLICK. You do not have the source ? Add the Jad decompiler. and voila. Want to see the super/sub classes and interfaces ? F4. Fast search all occurances of a method ? CTRL-SHIFT-G Until others languages have that king of IDE support, the only viable aternative would be C#, C++, Java and a few more. Not Scala, Python or other like that just have really basic IDE support...
  79. Yes, Java provides a good platform, IDE and all, but that would be enough only if you want to write and maintain a enterprise application/information system in it. You will face the limitations when you want to make something more complex than that, that is where Mario is coming from.
  80. Ridiculous. None of these are good reasons. However, there is something that Java is lacking and that Scala may solve: easier concurrency development
  81. so boring... move on[ Go to top ]

    why are we still posting threads like this? There is absolutely nothing new here, not even a few years new. It is very boring to read yet another re-hashed gripe session about very well known limitations to java. there are tons of postings everywhere about this stuff and scala and closures... why bother? Many people are already turned off to TSS, and posting old and boring thoughts are not helping things. Let's talk about something fresh. We can do better. -Adrian jclouds
  82. Re: so boring... move on[ Go to top ]

    why are we still posting threads like this? There is absolutely nothing new here, not even a few years new. It is very boring to read yet another re-hashed gripe session about very well known limitations to java. there are tons of postings everywhere about this stuff and scala and closures... why bother?

    Many people are already turned off to TSS, and posting old and boring thoughts are not helping things. Let's talk about something fresh. We can do better.

    -Adrian
    jclouds
    As someone who has actually been turned off TSS for three years I can tell you that passing tedious product releases for news was - and still is - the problem; for example: "jclouds releases updated beta for Amazon S3" or "PDF Library introduces consolidated logging" Fucking amazing, has anyone told the BBC?! Major breakthrough in computer science, a couple of programmers wrote 300 more lines of code, let's all get together and debate... Yeah, I'm very much aware that your pet project is the first there on the list, and that you've made headlines with two release announcements in about 3 months - for a beta and an updated beta! I can see how that's more important than people arguing about programming platforms - your product is obviously the solution to all their problems! 80% of the so-called "news" front page of TSS is a stupid HTML version of a freshmeat/sourceforge/google code automatic release RSS. It's beyond pathetic, really, as I remember there was a time when mainly editorials were posted and people had good debates on them for ages. I'd really rather have Rolf Tollerud back than this crap.
  83. I see your point on releases not being terribly exciting news. That said, they are news. At the point in time that we have enough news here to bump other news off the list, pre-releases are likely the first on the chopping block. I wouldn't argue with that. It doesn't mean we should put old news up as news in the mean time. my 2p. -Adrian jclouds (readying for another beta :p )
  84. Rolf Tollerud[ Go to top ]

    I'd really rather have Rolf Tollerud back than this crap.
    That was a good one ;) I've also been absent for 4 - 5 years now. Anyway, Rolf got me to become interested in "D" (remember those flames?), so it led to at least one positive outcome. Regards, Stefan
  85. The current Java situation is complex and depends on numerous past decisions. And while listing good reasons to look for something better than Java is interesting, IMHO it's interesting too to look at those decisions, that is, the Java context, that gives a broader view that could illustrate other topic of interests. (1) Java and the PHP threat (as an example of rising languages) As I wrote in my post PHP 5 is close to Java 1.4 and maybe even more much closer to JavaScript!, SUN has not treated appropriately the growing PHP menace. - Quercus: instead of developing JRuby and Jython, SUN would have done a better job while implementing itself Quercus (Quercus is a 100% Java implementation of PHP 5 with many PHP modules and extensions), and offering it with a very business-friendly open source license, or at a very interesting price. Then, hosting providers would have run the JVM instead of PHP runtime and one could expect more common and cheaper Java hosting as a side-effect. I have read into some articles that the Java platform, with all its API, was presented like a hub: from that point of view, SUN has missed the point to capture and integrate PHP mindshare. IMHO, providing a business-friendly open source Quercus-like implementation could be a good thing for Java hosting. Before Quercus, SUN has missed other opportunities too. Let's cite here some of them (detailed here): * Lack of functions (not enabling Java to leverage the procedural programming popularity) * Lact of a Java interpreted mode (complains about JVM startup cost, or the cost of the JSP compilation process, and the Java class hotswap problem) * License (being open source too late) * Programming model (one single JavaEE programming model being promoted, with a high entry barrier for newcomers) (2) Java (own) strengths have been forgotten Here are few examples: - RMI has been somewhat forgotten, and web services have been much more advertized (with cumbersome programming for little productivity for Java-to-Java communication), - JMS has been included into Java EE even if it is not object-oriented, while its object-oriented twin, JavaSpace, has been limited to Jini world, - a RDBMS has been included into JDK, while no object database has been promoted in a similar way: it's unfortunate the single storage promoted, here, by an object-oriented programming language is only a relational storage mechanism (see my post And now, something completely different for dealing with application properties for an original use of an object database for Java programming - Another use case is here). - and XML has been used all over the place, has been pushed forward a bit too much and even promoted inappropriately as a programming language (read Just Say No to XML by Allen Holub). - etc. So, on one side, Java has lost some of its strengths, for example, under the full XML fever, increasing programming complexity, and on the other side, Java has not improved easy of use programming to face PHP rising threat. Then, being in the middle, Java has been attacked from both sides. (3) Java looks like in maintenance mode I wrote before, Java looks like in maintenance mode (the problem with distributed language leadership ?). So, Java evolution is only made of small steps and this has consequences. Indeed, the problem is: adopting closures is one step, adopting type inference is another step, and adopting both, as the same time, while it would alleviate the closure burden, is a 2-step move that looks like too much enough for Java drivers, even if it looks like, IMHO, quite the best way to go to adopt closures. This explains why closures are still not adopted yet (this being said, I have proposed here a step forward closures, smaller/simpler than current closure proposals). To say things differently, Java is stuck into a local optimum (authorizing only small improvement steps), while a more global (and better) optimum (needing more simultaneous changes to be reachable) is just forgotten. So, while I see "Lack of closure" and "Lack of first class function" as top most interesting Java changes (just because they fit better with multi-core programmine, read here or here), I don't see, for example, closures adopted into Java without a good dose of type inference in order not to add too much complexity to Java. But, first, Java has to move out maintenance mode. (4) It's "sad" to see Java not evolving. Seymour Cray said once he didn't want to be a pioneer because pioneers make mistakes. Well, C#, and the different languages on top of JVM, just show different ways illustrating how Java could evolve. Even with that help, Java looks like in maintenance mode only. What a lost of a good occasion. First, some features could give a real plus, like functional features for a more easy multi-core programming. And secondly, some design decisions look like now half-backed. For example, MDB sounds like a particular case of actor specific implementation; Java would look better if those specific implementations were reworked according to already existing experiments into other existing languages. While, as one wrote, "Scala is much more complex than Java - a big leap for the average Java developer, and possibly a jump too far for most", I think it's not an excuse for Java to not evolve. Other languages' evolution, and/or complexity, is not an excuse for Java to stay in maintenance mode. IMHO, there is still room for Java substantial improvement. My 2 cents, Dominique http://www.jroller.com/dmdevito
  86. The 10 reasons listed are not very good arguments at first glance. Why do we need closures? Why are everybody talking about lambda and functional programming? Java works and why change that? I think that Scala probably is not better than java yet. But that is not the main issue here. The main issue is that we have a pressing need to go to a higher level of abstraction. This is because systems are getting very complex. The maintenance and development is getting problematic. Also the concurrency issues are getting problematic. So some people are saying the way out of it is using functional programming. Some are talking about message oriented architectures. Cloud is the new king some preach. Can scala deal better with these issues in the long run? I think so. Is it difficult to achieve another level of abstraction and concurrency with java? Yes, it is not easy. And it will get more problematic. Can you solve everything with Java? Ooh yes. So I agree that there is a need in the long run to switch to something else on the JVM.
  87. 2 cents[ Go to top ]

    I agree work needs to be done with java, but... #10 is total nonsense. Just because a martial art student slips down when he kicks doesn't mean you should get rid of kicking. The student has a problem, not the style. Same is true on checked exceptions. I've seen the .NET version of this debate. You may or may not get errors you expect, and when you do, the only way you know it to look at source or rely on the documentation. Lack of checked exceptions are a complete abomination. Exceptions and error handling are and should be part of all software development. They should be a forethought where meaningful information is returned. Some tools, like stripes, do a great job at this. Others, like Hibernate, are about as useful as Oracle SQL errors. The idea was to foster good error handling. The problem is everyone is looking for single hammer in hopes that everything turns into a nail. That's just not the reality of life or development. Error handling, log output, runtime state analysis, and unit testing should be parts of every project, which they aren't. In short, if you want better error handling, write error handling code. Try/catch might need a revisit, but removing checked exceptions for 100% unchecked ones makes developer life harder, not easier. The point is to make it easier, right? On the rest... 1 and 3 are serious valid issues. Number 6 I didn't know existed, and I think it a horrible idea. Typing in java is messed up, well at least from the developer point of view. Even JavaFX script it's easier to use in terms of typing than java. 2, 4, 5 are so so. 7 is just bad code structure on your part. You shouldn't be doing that as it's confusing and leads to a loss of understanding in terms of the results for more complicated code structures. In the spirit of Java, what would you be doing? Passing a printing function to someone else? There's a good reason pointers and virtual functions were left out. It needs to stay that way as making it 2 lines instead of 1 for improved readability makes more sense. 8 is akin to pointers, and was left out by design. I for sure don't agree with this one. cglib works if you really want to bend the rules. There's a reason you don't hand out hand grenades to high school kids. 9 is mute. At best you could say switch/case should just be dropped from the language as it's almost never used. Good discussion though.
  88. Re: 2 cents[ Go to top ]

    7 is just bad code structure on your part. You shouldn't be doing that as it's confusing and leads to a loss of understanding in terms of the results for more complicated code structures. In the spirit of Java, what would you be doing? Passing a printing function to someone else? There's a good reason pointers and virtual functions were left out. It needs to stay that way as making it 2 lines instead of 1 for improved readability makes more sense.
    You don't know what I actually want to do with it (I didn't go to much into details) so I guess it is at least difficult for you to realize if it does make sense or not. What doesn't make sense on my side is that void is not treated as an object and I really can't understand why.
    8 is akin to pointers, and was left out by design. I for sure don't agree with this one. cglib works if you really want to bend the rules. There's a reason you don't hand out hand grenades to high school kids.
    cglib is used in lots of mainstream framework like Spring and Hibernate. Do all of them bend the rules?
    9 is mute. At best you could say switch/case should just be dropped from the language as it's almost never used.
    switch/case is almost never used exactly for the reason I pointed out: because it is useless in this way. You are switching the cause and the effect in this case. Take a look at the case class in scala and you will understand what I mean.
  89. Checked exception: like primitive types, checked exception have been one of the original sins of Java. They oblige programmers to do one of the following two equally horrible things: fill your code with tons of poorly readable and error prone try ... catch statement where often the most meaningful thing to do is to wrap the catched exception in a runtime one and rethrow it; or blurring your API with lots of throws clause making them less flexible and extensible.
    I'm not sure why this topic is a love/hate relationship. I have never seen anyone actually answer it - there are always arguments, religious wars fought over this topic: http://stackoverflow.com/questions/613954/the-case-against-checked-exceptions Is it possible that we can get some real answer on how something can be better suited over the other. It's a bad idea to make the assumption that it's always abused by developers etc.
  90. Yes, there are some issues, some legacy, some addressable... but frankly, these do not significantly hurt my productivity. I just do not see ANY competing language/platform that can give me the breadth. From a productivity point of view, I think posting this article will negatively affect my output for the day more than the combined effect of all 10 points you raised. No way would I give up the breadth and depth of tools which are freely available. I find it very easy to develop understandable, performing solutions in Java. I also find that getting a team to work well together in Java is reasonably easy to do. My personal grievances would be more practical 1. Licensing (much much improved) 2. Desktop issues on linux (at least on Ubuntu) 3. FOOO (Fear or Oracle Ownership)... which I'm taking a "wait and see" approach on.
  91. Number 5 is not an issue[ Go to top ]

    5. Lack of generics reification: generics are one of the cool features introduced with Java 5, but in order to mantain the compatibility with the older version of java they miss some important characteristic. In particular it is not possible to introspect their generic type at runtime. For example if you have a method that accepts as parameter a List and you pass to it a List you are not allowed to know at runtime the actual type of the generic. For the same reason you cannot create array of generics. It means that despite it looks quite natural the following statement won't compile: List[] listsOfStrings = new List[3];
    You can create an array of generics, you just have the wrong syntax. Weather you use generics or not this is how you initialize an array. List[] listsOfStrings = new List[3]; listsOfStrings[0] = new ArrayList(); listsOfStrings[1] = new ArrayList(); listsOfStrings[2] = new ArrayList(); As for your other comments, no language does everything. If you need those things then yes, java may not be the best. You could use scalla, python, ruby or groovy on the jvm.
  92. Re: Number 5 is not an issue[ Go to top ]

    That was a poor example in the article. I think he was meaning more that you can't create a generic array using the template parameter. So, if your class includes a parameter, e.g. class MyClass {} then you can't have a statement like: T[] myT = new T[5]; That was just an example of how the generic type parameters are only used at compile time. If you want to know the generic class at runtime, your constructors need to include a class parameter that is that generic class, e.g. new MyClass(AnotherClass.class); Which is complex and unreadable.
  93. Better than Smalltalk?[ Go to top ]

    You said Java was a great improvement on Smalltalk. I'd like to see you justify that comment. As a former Smalltalk practitioner, I watched two companies shift to Java. In neither case was there a solid technical argument for the shift; it was more to do with industry trends and hype. A decade later, and having programmed exclusively in Java for that time, I still see no advantages to Java, over Smalltalk, other than it has had a ton of money and people thrown at it. So the tools are a lot better but that could have applied to Smalltalk. So if you have some influence over the language you use, then try a move back to Smalltalk. There is still a strong Smalltalk community out there, so you wouldn't be alone. My primary beef with Java is that it was, and will never be, fully object oriented. This has led, in my opinion, to a lot of programmers who know Java but don't know object orientation, leading to very poor code. It has also led to all sorts of complex mechanisms being introduced to both get round the non-object features, some of which you mention, and to let the non-OO programmers have their C facilities back (like enums and generics). Tony
  94. Re: Better than Smalltalk?[ Go to top ]

    Tony, Very well spoken, I have returned to a Smalltalk programming environment again and must say that it is a great relief to be back on the old camp again. Java always felt like a programming with a handicap. And the latest developments in the Java language make it indeed more complex to read and understand. I follow Gilad Bracha's posts on his blog and like what he is saying about imports. Check his blog: http://gbracha.blogspot.com/feeds/posts/default?alt=rss Regards, Yuri.
  95. Re: Better than Smalltalk?[ Go to top ]

    You said Java was a great improvement on Smalltalk. I'd like to see you justify that comment.
    well, i didn't write the original post that claimed that. however, i'm also an ex-smalltalker who has done Java for the last 8 years. i think Java the language is better than smalltalk in a team setting and Java the platform way better than Smalltalk the platform. here are my justifications for the language: - Java has (sort of) strong typing which i find better for team programming. i used to get lost in large smalltalk code that wasn't documented with type annotations. no methodnotimplemented callbacks generally. - because it's statically typed, the refactoring tools are better. the refactoring browser in smalltalk could never guarantee to make all the changes in a typesafe way. only whole program analysis and much more complex tools can fix this, and even then they have to be conservative. - less rope to hang yourself with. doing direct modifications of the core classes in smalltalk is cool, but no great for a team where you have a range of abilities. here are my justifications for the platform: - the JVM has far better threading than any commercial smalltalk i ever used. even envy/VA was singly threaded and used async call outs for blocking IO. yuck. - the performance is way better than any commercial VM i've ever used. by something like 5x. the smalltalk vendors kept going on about how they'd eventually make it faster than a statically typed language like C++. never happened, probably never will. - the range of libraries in the Java platform is superior - the JVM is more open to inspection. no image concept, which means that classes live outside of the vm.
    So the tools are a lot better but that could have applied to Smalltalk
    i don't think this would ever be the case. the dynamic typing of smalltalk makes some tools very, very difficult to write. remember that eclipse is made by the same people who did the VA toolset.
    My primary beef with Java is that it was, and will never be, fully object oriented. This has led, in my opinion, to a lot of programmers who know Java but don't know object orientation, leading to very poor code.
    oh, boy, i've seen some bad smalltalk code in my day.
    It has also led to all sorts of complex mechanisms being introduced to both get round the non-object features
    now, that's definitely true.
  96. Autoboxing Bugs in Scala[ Go to top ]

    I've been looking at Scala during my summer vacation. Lovely language, would be much easier to teach than Java. However, the problems and bugs in Java do seem to leak through Scala as well. For example, you can easily get autoboxing bugs in the latest version of Scala. Try this: val numbers = new java.util.IdentityHashMap[Int,String] numbers.put(1024, "small-enough") numbers.put(1024, "small-enough") numbers.put(1025, "too-big") numbers.put(1025, "too-big") numbers Output is res67: java.util.IdentityHashMap[Int,String] = {1025=too-big, 1024=small-enough, 1025=too-big} Unlike Java, Scala is not symmetrical in the ranges, so -128 uses the shared object, but -129 does not. Have fun ... :-) Heinz
  97. Try Groovy Instead[ Go to top ]

    Hi, I was faced with exactly the same issues you mentioned in your article. Have you tried Groovy? It pretty much covers all the issues you talked about. See http://groovy.codehaus.org/ Cheers, Stephan
  98. Re: Try Groovy Instead[ Go to top ]

    I was faced with exactly the same issues you mentioned in your article.
    Have you tried Groovy? It pretty much covers all the issues you talked about.
    I don't like dynamic languages, so I prefer Scala. And the interesting thing is that even James Strachan (one of the Groovy creator) seems to agree with me :) http://java.dzone.com/articles/scala-long-term-replacement Bye Mario
  99. Please Keep Java Language Stable[ Go to top ]

    To live longer, stability is very important. When adding new features into the Java language, it is necessary to be conservative. I'm already unhappy with Java 1.5 language features. New languageg features add a very big deal of complexity to the overall Java platform. Competing with dynamic language is not a way we want to follow(IMHO, C# competition already hurt the Java language). Dynamic language lovers may change their language and add all the features listed here to their favorite language but don't touch Java please.
  100. Hello Mario! My name is Lucas, I'm from Brazil. I want to translate your text into Portuguese. Can I do this?
  101. My name is Lucas, I'm from Brazil.
    I want to translate your text into Portuguese.
    No problem on my side about that. Actually I don't know if the editor (somebody in TSS) should allow that as well, but I don't think so. If you make this article available in Portuguese please post the link. Thank you Mario