Loading ...
Sorry, an error occurred while loading the content.

Previsioni 2007, Java, Linux e altro

Expand Messages
  • Vincenzo Ing. Virgilio
    But what happens next? That s the big question. As with a lot of this year s events, it s not obvious what this move will lead to, rife as it surely is with
    Message 1 of 1 , Jan 4, 2007
    • 0 Attachment
      But what happens next? That's the big question. As with a lot of this
      year's events, it's not obvious what this move will lead to, rife as it
      surely is with unintended consequences. So for this year's "2006 In
      Review" article, we're taking a different approach: we're listing some
      of the major developments and pointing out what to look for in 2007 as a
      results of those events.

      Review/Preview: 2006 and 2007 in Java

      by Chris Adamson <http://www.onjava.com/pub/au/1045>

      Unlike previous years
      2006 has been a defining year for Java, marking fundamental change for
      what remains, by many objective measures, today's most popular
      programming language. Most critical to the fate of Java is Sun's
      decision to release its implementation of Java under terms of the GPL, a
      process that is well underway today with the release of the HotSpot VM
      <https://openjdk.dev.java.net/hotspot>, javac compiler
      <https://openjdk.dev.java.net/compiler/>, and a GPL Java ME
      <https://phoneme.dev.java.net/> implementation (Java EE was open-sourced
      last year as the GlassFish <https://glassfish.dev.java.net> project).
      The SE pieces aren't enough to comprise a complete Java platform
      yet--that will happen next year when the class libraries are
      open-sourced. Still, the progress is a lot more than almost anyone would
      ever have predicted a year ago, and virtually nobody expected Sun to
      choose GPL for its open source license.

      Open Source Java

      2006: Sun open-sources <http://www.sun.com/software/opensource/java/>
      its Java VM and compiler under the GPLv2
      2007: Watch for class libraries... and forks

      The GPL release of the Java compiler and VM shows Sun is serious about
      open-sourcing Java, but it's too soon to see what the results will be.
      For one thing, the released code is basically a very early Java SE 7, as
      Sun didn't want the open source work to interfere with the release of
      Java SE 6, which happened earlier in December. Along with being a
      pre-spec VM, the release also lacks the class libraries that would be
      needed to bring up a useful Java environment.

      One of the challenges in providing the class libraries is having to
      search millions of lines of code for encumbrances, code that Sun
      licensed to use in Java and that it doesn't have the rights to GPL. Some
      of these may have suitable drop-in replacements from the open source
      world, but sooner or later, it's inevitable that there'll be some things
      that Sun will need to relicense, rewrite, or omit.

      The big question beyond this is what people do with Java now that it's
      GPL. Beyond solving the political issues involved with including Sun's
      JVM with certain Linux distros, and getting the JVM ported to platforms
      that Sun itself isn't interested enough to do its own versions for,
      there's the question of what unpredictable things people will do with
      the bits. Does HotSpot's dynamic runtime compiler offer something to
      other languages' runtime? Will developers fork the language itself by
      hacking the compiler to add or remove language features? The result
      can't be called Java, but so what? Maybe Java could be used for
      domain-specific languages, in which case there'd be no desire to call
      the resulting variant "Java" or anything that starts with a "J."

      2006: Sun creates and promotes Distro License for Java
      2007: Does it matter anymore?

      If you're a Linux distro, it should be obvious by now that Sun is
      totally smitten with you. Even before the surprising GPL-ing of Java,
      Sun was making overtures to the Ubuntus and Debians of the world with
      the Distro License for Java, which lets the platform developers package
      Java SE in a form that makes sense for their platform, so users can get
      a JVM with something like an apt-get rather than having to do some sort
      of hand install.

      Of course, with the GPL release of Java, the need for the DLJ would
      seemingly go away; any changes necessary to the JVM, its class
      libraries, or the form of its release can readily be made, provided
      those changes are themselves published under the GPL--and GPL
      compatibility was the whole issue with most of the Linux distros anyway.
      So, on the surface, the DLJ would appear to be necessary only until GPL
      Java is itself ready to be stuffed into a .dpkg. But how long will that be?

      The Java Platforms

      2006: Java SE 6 released
      2007: When will developers adopt it?

      A little behind its original schedule, Java SE 6
      <http://java.sun.com/javase/6/> arrived in mid-December. The new version
      offers a smattering of new APIs including XML Digital Signature, updates
      to essential APIs like JDBC 4.0 and JAXB 2.0, a re-architected
      graphics-rendering pipeline, greater fidelity in Swing's Windows and GTK
      look-and-feels, and more.

      But given the deliberation with which many Java developers, deployers,
      and users adopt new versions of Java (anecdotally, the nearly
      five-year-old Java 1.4 still seems to be in wide use), what about SE 6
      will get people to switch? Unless you need some specific feature, say,
      JDBC 4.0's SQLXML data type, will it be worth installing a whole new
      JVM, and a "dot zero" release at that? Performance
      improvements--particularly for desktop apps--notwithstanding, we may be
      well into 2007 before SE 6 is assumed to be the default version.

      2006: Java SE 6 runs languages other than Java
      2007: What languages will you be running on the JVM?

      Perhaps the most interesting change you can point to is SE 6's built-in
      support for scripting languages. The new javax.script APIs allow you to
      instantiate and use scripting language engines in Java, and to exchange
      data between the language and Java. Java SE 6 provides built-in support
      for JavaScript (via the Rhino engine), and more languages are certain to
      be added by third parties.

      The obvious "next language" may well be Ruby, given that Sun hired
      the developers of JRuby <http://jruby.codehaus.org/> in September. Not
      only does this elevate the status of Ruby within the Java world, but
      some have also noted that it has already sped up the JRuby release schedule.

      The idea of running other languages on the JVM is nothing new, of
      course--Robert Tolksdorf's list
      <http://www.robert-tolksdorf.de/vmlanguages> shows over 200 language
      options for the JVM--but Ruby is special given the buzz surrounding Ruby
      and the Rails framework as a rival to Java for building enterprise
      web applications. This was the major theme of Bruce Tate's book Beyond
      Java <http://www.oreilly.com/catalog/beyondjava/>. But another often
      overlooked point of Tate's book was the idea that the JVM solves so many
      essential problems, such as security and cross-platform compatibility,
      that any successor to Java would likely need to run on the JVM. In other
      words, nobody wants to start over with an insecure language or framework
      that ties you to one platform.

      Is Sun co-opting the Ruby buzz, or picking favorites? Maybe a little of
      both, but there's a deeper story here; as much as pundits talk about
      Ruby/Rails' potential to steal an audience of Java developers, it's
      clear that it's also luring developers away from other scripting
      languages, such as Perl and PHP.

      2006: JDK 7 development begins
      2007: The closures argument comes to a head

      JDK 7 <http://jdk7.dev.java.net/> development is already underway,
      although it will be some time before a set of features for this list
      comes together. Surely the most debated language feature on the JDK 7
      table is the proposal to add closures to the Java language

      In essence, there are really two arguments here. The first is whether
      closures are needed at all, or whether the increase in complexity
      outweighs the benefits closures would provide in specific cases. Given
      that some of what closures provide is already accomplished by anonymous
      inner classes, the specific pain points that closures would alleviate
      may simply not justify another language structure. The second argument
      is about the specific syntax of the closure proposal, and whether its
      apparent desire for compactness may make Java closures unnecessarily
      hard to read.

      2006: Java EE 5 released
      2007: Will EJB 3 win back developers?

      Java EE 5 <http://java.sun.com/javaee/5/> was released this summer and
      with it, EJB 3.0, the profound reworking of the much-maligned enterprise
      object framework.

      The story to watch for in 2007 is whether EJB 3.0 can win back the
      developers who abandoned the pedantic EJB 2.x approach in favor of
      simpler approaches to business logic (Spring
      <http://www.springframework.org>) and persistence (Hibernate
      <http://www.hibernate.org/>), or if that audience has found what it
      needs in the alternative frameworks. And if EJB can't win them back, is
      that really bad for anyone other than Sun and the various EE licensees?

      2006: Java ME still on every phone
      2007: Does a GPL ME change anything?

      Java ME seems to attract the least notice or attention of the three
      major Java platforms, even though its distribution on mobile phones
      would presumably make it more ubiquitous than SE or EE. Some of that,
      surely, comes from application distribution problems caused by the
      difficulty of working through mobile service providers, at least in the
      U.S. So while there's now an open source CLDC/MIDP platform
      <http://phoneme.dev.java.net>, it's an open question as to what anyone
      will do with it. While manufacturers may choose to stick with current
      licensing arrangements, a GPL ME might be ideal for upstarts in other
      small device spaces.

      Beyond the Sun

      2006: BD-J makes a splash as part of Blu-Ray
      2007: If Blu-Ray crashes and burns, will it take BD-J with it?

      One novel use of Java ME is to provide the interactivity platform of the
      Blu-Ray Disc standard, one of two competing formats for high-definition
      movie systems (the other being HD-DVD). The standard includes the
      Java-based "BD-J" environment, which marries Java ME with some APIs
      borrowed from interactive television, to provide highly interactive
      menus and other potentially novel content, including network
      access from movie discs. Blu-Ray backers point out that the standard
      needs more compelling interactivity than is provided by DVDs as a
      distinguishing feature to help the format succeed; just having a clearer
      picture isn't enough to get people to switch.

      But will it work? Blu-Ray's main proponent, Sony, has had a miserable
      track record in the press recently, between its rootkit and exploding
      battery fiascoes. Making Blu-Ray part of the PlayStation 3 was meant to
      be a boost to the standard, but instead it may actually be hurting the
      PS3, as gamers
      blame Blu-Ray
      for increasing the price and slowing production of the PS3. Worse for
      BD-J, Sony's first standalone Blu-Ray player doesn't actually support
      <http://blogs.business2.com/utilitybelt/2006/12/sonys_1000_blur.html> ,
      with Sony saying that BD-J functionality will be provided in a 2007
      firmware update.

      Earlier this year, your editor went to a JavaOne session on Blu-Ray in
      hopes of getting information on developing for BD-J, and came away
      deeply disappointed
      Now that Blu-Ray's presumed success is no longer a fait accompli, the
      question of whether developers can get a BD-J SDK without paying
      enormous license fees may not even matter.

      2006: Eclipse Callisto offers ten simultaneous releases
      2007: What's succeeding other than the IDE?

      All indications are that the Eclipse IDE remains the top choice for Java
      development. But Eclipse is much more than an IDE. The Eclipse
      developers reminded everyone of that with this summer's Callisto
      <http://www.eclipse.org/callisto/> release, the simultaneous drop of ten
      different Eclipse foundation projects.

      Having said that, it remains to be seen just how much success Eclipse
      can muster beyond the IDE. The building blocks of Eclipse can be used to
      create rich client applications, in the form of the Rich Client Platform
      <http://wiki.eclipse.org/index.php/Rich_Client_Platform> (RCP), but it's
      not clear how many developers have adopted this model. Eclipse's
      Standard Widget Toolkit (SWT) was supposed to be the answer to the
      problems of Swing, but after years of development, it seems as common in
      the wild as Swing--that is to say, not very. The rival widget toolkits
      can each claim credit for one IDE (Eclipse and NetBeans), one
      file-sharing program (Azareus and LimeWire), and not much else. Will
      2007 be the year SWT lands on the desktop
      in a big way, or are it and Swing big ducks in a small pond?

      2006: Google releases GWT
      2007: Is GWT the new face of Ajax?

      Introduced at JavaOne 2006, Google Web Toolkit
      <http://code.google.com/webtoolkit/> offers an audacious and unexpected
      approach to writing Ajax applications: you write Java code with UI
      objects not unlike those of the Swing and SWT frameworks, and GWT will
      compile it into client-side JavaScript, handling all the various browser
      compatibility miseries for you. There's immense potential to spare
      developers from low-level JavaScript debugging, but it will be
      interesting to see if developers are willing to cede so much control to
      their framework, or if they will insist on hand-rolling their own client
      and server code.

      2006: Google deprecates SOAP search API
      2007: Is this the beginning of the end of SOAP?

      Just this week, InfoQ noted
      <http://www.infoq.com/news/2006/12/google-search-api-gone> Google's
      deprecation of its SOAP Search API
      <http://code.google.com/apis/soapsearch/>, in favor of an Ajax-oriented
      alternative that's better suited for client-side use than server-side.
      O'Reilly Radar blogger Brady Forrest called
      it a "a unilateral move that is going to alienate at least some of the
      Google dev community and lead to defections to other services," and
      worried about the effect on web services as a whole, since it was in
      many ways the canonical web service. Steve Loughran goes further,
      calling it The end of SOAP
      and shedding few tears: "it won't happen at once, it won't be overnight,
      but one day SOAP will be over. We will look back and wonder 'what were
      we thinking?'. It will be up there with ActiveX, EJB2, and other things
      that we will describe as mistakes that should never have made it past
      the powerpoint stage."


      2006: JSR 306 proposed to reform JCP
      2007: Can the JCP make all the people happy?

      JCP 306 <http://jcp.org/en/jsr/detail?id=306> was approved in August,
      under the daunting title "Towards a new version of the JCP." Among its
      goals are improving the transparency of the Java Community Process,
      improving the involvement of individuals, and optimizing the duration of
      JSRs. Also in its charter are possible changes to improve working with
      other standards bodies, working with non-Java implementations, easing
      migration of existing technology into JSRs, and making TCK and licensing
      information available upon conclusion of a JSR.

      The expert group's early draft review was tentatively scheduled for this
      month, with a public draft review in February 2007, a final draft in
      April, and the final approval ballot in May. This proposal needs to pass
      both the SE/EE and ME executive committees, and it's sure to get a close
      look, particularly following the criticism JSR 277
      <http://jcp.org/en/jsr/detail?id=277> received from OSGi and others
      who've worked on problems similar to 277's "Java Module System."

      2006: Java book sales continue to decline
      2007: What's declining, Java or books?

      In his most recent survey of the State of the Computer Book Market
      <http://radar.oreilly.com/archives/2006/11/state_of_the_co_1.html>, Tim
      O'Reilly notes the continued slide of Java book sales, down 15 percent
      in the last run of the stats. He writes:

      The decline of Java book sales has accelerated, while C# books have
      continued their steady increase. When you aggregate books on both C#
      ".Net Languages" (books that cover both C# and VB.Net), the C# book
      market is now about 12% larger than Java. (Of course, some of those
      .Net Languages book purchasers could be buying them for their
      coverage of VB.)

      Perhaps it's not surprising that 2005 would have moved more books in
      support of the language changes in Java SE 5, and that 2006 would be
      slower with no such changes in SE 6. That said, the Java book market is
      an odd beast; few titles can be relevant to all Java programmers, and
      the various topic niches and programming frameworks may be too small to
      support books on them. How many Java web frameworks are there, and how
      many have enough of a professional following to sell a lot of $40 books?
      It's possible that the future of Java content may be in different forms,
      like the O'Reilly Short Cuts
      <http://www.oreilly.com/store/series/sc.csp> PDFs, or online articles
      like those here on ONJava and java.net.

      Your Turn

      So that's a brief overview of some of the 2006's most prominent Java
      happenings, and what you might look for in 2007. But what do you think?
      What's happening in Java from your point of view, and what should we be
      looking at next year? What did we cover too much on ONJava this year,
      and what would you rather see covered more in 2007?

      To finish out this year-ender, let's hand it over to you, the
      readership. In the Comments section below, please let us know what
      matters to you as Java developers, and how ONJava can help you make the
      most of the opportunities that Java provides.

      But one last thing before the comment block begins: thanks for reading
      this year. See you in 2007.

      Chris Adamson <http://www.onjava.com/pub/au/1045> is the editor for
      ONJava and java.net, and is an Atlanta-based consultant, specializing in
      Java, Mac OS X, and media development.

      [Non-text portions of this message have been removed]
    Your message has been successfully submitted and would be delivered to recipients shortly.