2007: What to Expect in the Java Universe

Discussions

News: 2007: What to Expect in the Java Universe

  1. 2007: What to Expect in the Java Universe (28 messages)

    Elliotte Harold, Adjunct Professor at Polytechnic University, has an interesting analysis of what to expect from Java in 2007 and where the language and platform are headed. He also discusses the side-effects from the decision to open the Java source such as trends in the Java tools area, and the implications for other technologies like Ruby and Python. About Java going open-source: Before 2007 is half up, Sun will release the Java Development Kit (JDK) under an open source license. Freeing the JDK is a huge step for the Java developer community, and it will drive the evolution of the Java platform for the next decade... unfortunately, design is not as parallelizable as debugging and optimization... look for forks at all levels of the Java platform: language, virtual machine, and libraries. Most of these will fail, but that's okay. The good ideas will rise to the top. Elliotte goes on to describe his ideas and expectations about Java 7, client GUI development, JEE and JME. What do you think? Will an open source Java continue to evolve in the 'right' direction?

    Threaded Messages (28)

  2. E. Rusty Harold deserves a lifetime achievement award for blogging about java and XML. He has to have the longest running blog (www.ibiblio.org/javafaq). Back in the 90's he was pretty much it for Java news. His ascii i/o is phenomenal. Nothing stands out in his analysis as not-predicted but I do see a meta-trend of tools and technologies branching and merging over time. It's just the desktop operating systems that have become more hostile to java. Go Rusty!
  3. Groovy vs. JRuby[ Go to top ]

    For someone that is supposedly a Java sage, is sad to see how far from the heartbeat of where Java is headed this person is - I refer to the matter of Ruby on the JVM. Groovy is by far the superior choice for a dynamic language to run on the JVM. If you're deep into the Java community then you're well aware of that point, and you're well aware of the incredible momentum Groovy has picked up over the last year. Is quite amazing as to how Groovy can be an immediate asset to the daily life of a professional Java developer - and no you don't have to get approval to run Groovy as production code. Used in many other capacities in the process of developing Java-centric software it will quickly make itself utterly indispensable. Is interesting that the rank and file Java folk are choosing Groovy while the Sun execs blessed JRuby. They've been wrong so many times before, though, on matters Java that this is not at all surprising. Never seen a company that at the top (where the shots are called) can be so out of touch with its very own creation. BTW, the guys doing JRuby are perfectly nice - it's just that from a Java developer's perspective Groovy turns out to have a lot more to offer. Also, there is only so much mind-share-budget for picking up new tools, etc. So to spend wisely to get the greatest benefit, one spends mind-share-budget on Groovy instead of JRuby.
  4. Re: Groovy vs. JRuby[ Go to top ]

    "Groovy is by far the superior choice for a dynamic language to run on the JVM. If you're deep into the Java community then you're well aware of that point, and you're well aware of the incredible momentum Groovy has picked up over the last year." I think you overstate the case..... I've seen much more written about JRuby in the past few months than Groovy. I think this stems primarily from the huge interest in getting Rails to run on the JVM. I don't know Groovy, so I don't have an opinion on Groovy vs Ruby as a language. But from what I've seen JRuby has more momentum and interest. Hard to prove as a google or technorati search for groovy brings up way more stuff than Groovy language related material.
  5. Re: Groovy vs. JRuby[ Go to top ]

    I don't know Groovy, so I don't have an opinion on Groovy vs Ruby as a language. But from what I've seen JRuby has more momentum and interest. Hard to prove as a google or technorati search for groovy brings up way more stuff than Groovy language related material.
    I think you have to know Groovy to understand the issues. The problem with JRuby is that it was not designed from the start for integration with Java - it is largely just Ruby ported to the JVM. So, there will always be at least some conflict between the Ruby way of doing things and the Java way. Ruby has a hugely different syntax, and has different implementations of classes and libraries - some of which overlap considerably with those of Java (such as String). It will undoubtedly be very easy to write normal Ruby code using JRuby, but if you try and use it with Java you could end up with code that is unfamiliar to either a Ruby developer or a Java developer. Groovy was designed for Java integration from the start, and based on Java syntax. It is possible to write Groovy that can be understood by a Java developer with little explanation. Groovy can use all Java classes directly - no need for renaming some of them to avoid conflicts (as with JRuby). All Groovy code can compile to byte code (so can be optimised), and you can freely mix dynamic and static typing. I have given up trying to understand what 'momentum' means in this area - there is so much (possibly unintentional) selective reporting and spin, and I personally don't believe number of blog entries and news articles about something has much relation to actual use or take-up of a technology. My impression from news about what is happening at various meetings and conferences is that Groovy is really starting to get used - the recent release of version 1.0 was significant.
  6. Re: Groovy vs. JRuby[ Go to top ]

    The only reason it's been getting so much press is because people think it's such a big deal that Sun sucked up the JRuby team. There's been a zillion stories released about that I frankly couldn't care less that Sun is maintaining the project. It was being well maintained prior to that. In any event, prior to that point, JRuby pulled little interest in its wake. Oh, and there's the endless effort of Ruby fanatics to mention or report anything that has anything to do with their blessed language. Ruby fanatics != Java programmers who need a scripting language.
  7. Re: Groovy vs. JRuby[ Go to top ]

    "Groovy suffers from a lack of a clear vision and a penchant for choosing computer-science buzzwords over usability and familiarity." The shear inanity of this one sentence from the author completely underminds everything else he writes. Is a hallmark signature of someone speaking on something they either know nothing about, or else have an axe to grind due to some undisclosed bias.
  8. Interesting article, although I would question some points. I just can't see Ruby becoming the scripting language of choice on the JVM. To be successful in this role, a language has to have truly seamless integration with Java classes and libraries. JRuby doesn't seem to, and there will always be some degree of mismatch between the Ruby implementation of things and the Java equivalents (such as with Strings). My impression is that Groovy (for all its faults) has far more support than the article suggests, and I am hearing regular news about Grails. I would also be interested as to why generics are considered by some a 'debacle'. I have found it hugely improves type safety and refactoring, and I can't imaging going back to the degree of casting I used to use with Java 1.4. Perhaps the comment was about the specific implementation? Other than that, I am encouraged by the Java 7 suggestions - I have long been a supporter of operators for BigDecimal and BigInteger.
  9. Will it be Groovy or Ruby?[ Go to top ]

    +1 Steve. I've been using Ruby for over 5 years for all kinds of things and I love it. I'm not even into Rails, but I really like Ruby. However ... I do most of my serious/paid work in Java, but I use scripting languages a lot too for various things, on and off the Java projects. For scripting work in a Java environment, I prefer Groovy over Ruby, mainly due to its great integration. Groovy has really shaped up well. I think a lot of people got turned off Groovy because of the early versions and some of the hype. I did too. But they should revisit it with an open mind. I moved a bunch of Ruby code in our project over to Groovy recently. It went painlessly and it is a big improvement. I now have more reach via all the Java libraries, not the least of which is JDBC. Invocation of Groovy scripts in the project is now in Ant, like everything else. And the Groovy code runs about 10x faster than the Ruby code did. Groovy rocks today. John Hurst Wellington, New Zealand
  10. Re: Will it be Groovy or Ruby?[ Go to top ]

    I agree. Groovy used to suck but now it's pretty sweet and I think it will be getting a lot sweeter. If you're mostly dealing with Java development, Groovy is a FAR better choice than Ruby for scripting. It's syntax is much more familiar to Java developers and it's Java integration top notch. Groovy's primary con is that the IDE support isn't where it should be. Hopefully that will change soon.
  11. Interesting article, although I would question some points.

    I just can't see Ruby becoming the scripting language of choice on the JVM. To be successful in this role, a language has to have truly seamless integration with Java classes and libraries. JRuby doesn't seem to, and there will always be some degree of mismatch between the Ruby implementation of things and the Java equivalents (such as with Strings). My impression is that Groovy (for all its faults) has far more support than the article suggests, and I am hearing regular news about Grails.
    Agree with all of that, but I'd just add that it would seem that many Java developers would be more comfortable with a type-inferred language like Boo that has the feel of a scripting language, but with the benefits of static typing.
  12. To be successful in this role, a language has to have truly seamless integration with Java classes and libraries. JRuby doesn't seem to, and there will always be some degree of mismatch between the Ruby implementation of things and the Java equivalents (such as with Strings).
    -1 Maybe you are smarter than me...but can you do this: http://www.meagle.com/articles/2007/03/05/java-through-ruby-through-java
  13. Yes, that's the whole point. Spring's scripting bean support is wonderful, but the fact that you need all this stuff in order to interoperate between Java and JRuby is why we say Groovy interoperates seamlessly. You can of course use Spring to wire up Groovy beans just as you can JRuby beans. But you don't have to. You can simply instantiate Groovy classes from Java and vice versa. If I'm building components in a layered architecture, I want to use dependency injection and all that good stuff with Spring. But there are lots of other times, like when writing a quick script, when I prefer just to instantiate what I need and get going. Regards John Hurst Wellington, New Zealand
  14. OSGi support in 2007?[ Go to top ]

    What I am missing in this 2007 preview article is the initiative the Spring framework is taking to include OSGi support. OSGi will allow deploying an application in a OSGi 'service space' as different 'modules' (or 'bundles'). These modules can be fully managed by the OSGI service space (started, stopped, upgraded, installed etc..). For a lot of architects this support will bring new ideas and architectures (especially in distributed and/or mobile applications)... Bart Hansen
  15. Sun is taking another whack at this problem with the Java Module System
    ... the problem that Maven tries to solve
    Possibly JSR 203 will finally fix this and give us a plausible, cross-platform file system API
    ... problems (partially) solved by commons-io
    Sun already offered a 'standard' logging API as an alternative to log4j, at some points being better and at some being worse. And now we're doomed to use commons-logging.
    I sincerely hope this won't happen again, but I'm pessimistic about this.
    I do most of my serious/paid work in Java, but I use scripting languages a lot too for various things, on and off the Java projects. For scripting work in a Java environment, I prefer Groovy over Ruby, mainly due to its great integration.
    I completely agree.
    IMO it's better to use Java and Groovy in parallel than trying to extend Java in a non-natural way (look what happened with C++). This way developers have a clear choice: use plain Java for frameworks and performance critical stuff, use Groovy for the rest. Houbrechts IT, agile Java development
  16. I completely agree.

    IMO it's better to use Java and Groovy in parallel than trying to extend Java in a non-natural way (look what happened with C++). This way developers have a clear choice: use plain Java for frameworks and performance critical stuff, use Groovy for the rest.
    2 years ago we started with implementing processes. Now we are using Groovy for mail generators, screen validation, ... . Last month I'm thinking about using Groovy for process action writing. For now our processes are done in Java but is very unflexible. Groovy is great.
  17. IMO it's better to use Java and Groovy in parallel than trying to extend Java in a non-natural way (look what happened with C++). This way developers have a clear choice: use plain Java for frameworks and performance critical stuff, use Groovy for the rest.
    I like this approach, and it is why I am not sure about the need for closures in Java, when you have them in Groovy.
  18. IMO it's better to use Java and Groovy in parallel than trying to extend Java in a non-natural way (look what happened with C++). This way developers have a clear choice: use plain Java for frameworks and performance critical stuff, use Groovy for the rest.


    I like this approach, and it is why I am not sure about the need for closures in Java, when you have them in Groovy.
    For those of use who don'tuse Groovy. I don't think the optimal choice is to have to use both to get the features that should be in one.
  19. I don't think the optimal choice is to have to use both to get the features that should be in one.
    Adding all those features to Java, while keeping it backward compatible, will turn it into an ugly beast:
    • closures: all the proposals for JSE7 I've seen so far, only provide a fraction of the power of Groovy closures, and they introduce more complexity then they solve problems
    • generics: I agree with Elliotte Harold calling this a debacle. I have yet to meet an (experienced) Java developer who can explain the meaning of Class Enum> in the java docs of enum.
    Houbrechts IT, agile Java development
  20. I agree that nested generics are a perfect example of "generics gone wrong", but at the same time, why is it important to understand that statement if all you want to do is use enums? I use typed collections whenever I use Java. I cannot say that Generics were completely wrong.
  21. Class Enum> Should actually be Class Enum>. But after a little experience it's not all that hard to understand. If you want to make a type parameter that refers to the class itself for either interface implementation or method usage, then you make the type parameter extend itself. That causes the extends Enum part. But in order to refer to the Enum class safely, you need to declare the parameter type. Luckily, you can just reuse the E that have already declared. Hence the Enum part. In the end it allows you to do what I call a circular reference. I am not sure if that is the accepted vernacular, but that is how I explain it. I will admit that making classes with generics is a bit daunting at first. But after a week or so, it becomes not only second nature, but it also becomes much easier to work with. Less coding since there is no casting or instanceof checks. I will not disparage those who don't like generics. If you don't want to use them, you are not forced to. John Murray Sobetech
  22. Package Access[ Go to top ]

    I'm also hopeful that Java 7 will relax access restriction just a bit. It may become possible for subpackages to see the package-protected fields and methods of classes in their superpackages
    Conversely I would like subpackages that could restricted access and were then only accessible to their superpackage.
  23. Re: Package Access[ Go to top ]

    http://www.jyog.com sudhir nimavat
  24. Re: Posting your own blog[ Go to top ]

    What exactly do you think your own web page has to do with the subject matter? Looking for a job? Why do you think anyone is likely to give you a job when posting random links on unrelated threads on TSS ? The only think likely to happen is that people think that this person has attention deficiency and not vaguely employable
  25. The only think likely to happen is that people think that this person has attention deficiency and not vaguely employable
    No, it's SEO technique. The more links to a page, the higher is the page rank in Google etc. Hey Suhdir, think of your karma, you won't improve it by tricks like that.
  26. Re: Posting your own blog[ Go to top ]

    + infinity (Raul) What a disgusting act… I wonder even if he has a clue - what are we talking about here. Anyways, people make mistake and I advise you not to repeat this kind of act again. Amit
  27. JSR 296[ Go to top ]

    Java SE does not provide any support for structuring [swing] applications, and this often leaves new developers feeling a bit adrift ...
    This is very true. If you want to develop a web application there are dozens of frameworks out there to help you, but little to help you build a swing app. I've worked on some large swing applications using the traditional MVC idea, but they always grew into horrible monsters. Eventually I tumbled to the idea of building my own state-based framework that was modelled on Struts. I made a long rambling post about it here. My biggest gripe about swing has not been about speed nor about what is possible, it has always been about how difficult it is to use it. I will watch JSR 296 with interest.
  28. Re: JSR 296[ Go to top ]

    Eventually I tumbled to the idea of building my own state-based framework that was modelled on Struts.
    Oddly, Struts development makes me prefer Swing, whatever the pain might be.
  29. Can we expect JSR 310 be part of Dolphin?