Java Standard Edition 6 has formally gone to beta status today, downloadable from Sun. The beta includes the new scripting framework, the JAX-WS client stack (with JAXB), greatly enhanced diagnostics (especially if you're running on Solaris 10), desktop enhancements, and a number of other changes. Sun expects JSE 6 to be finalized in August 2006.

The scripting framework is currently only the framework. While a script language (such as JavaScript) may be bundled eventually, the goal for JSE6 is to provide hooks for scripting languages rather than including one or more. However, the scripting language hooks are very broad, with the intent being that one would be able to embed Perl, Ruby, Python, Groovy, JavaScript, or others, with native implementations of the languages being allowed (i.e., not necessarily JRuby, but the actual Ruby binaries.)

The web services client bundled with JSE6 is the client side of JAX-WS 2.0, as well as JAXB. Early reports had suggested an HTTP server might be included with JSE6, but that's been dropped in favour of focusing on client services only.

The diagnostics features are mostly exposed via JMX, with the ability to drill down to specific threads (and deadlocks associated with threads) and many other capabilities as well. In addition, if JSE6 is deployed on Solaris 10, hooks for the dtrace utility are part of the JVM. While dtrace is specific to Solaris 10, the JVM hooks are part of the bundled licensed code, so other vendors will be able to provide similar hooks for other tools if they so choose.

Desktop enhancements include better look and feel support for various operating systems, including Windows Vista.

Performance and runtime impact are majour goals for the JVM team, with distinct improvements over previous JVMs being a goal, from a conversation with Bill Curci, product marketing manager for the Java Platform SE. He said that download size for the JRE was a consideration, but did not specify any goals for installation.

Sun has tried to involve the community heavily in this revision of the JDK, offering a new license and rewards for regression testing although the real reward for regression testing is a better product - and Sun is interested in regression testing with client code, even if you think compatibility issues are the fault of the user's code and not the JVM. What do you think of the process and results so far?

Sun/JCP can't be serious. This is hardly a major upgrade and seems rushed. Looking at the major enhancements 1.4 and 5.0 brought, I wonder why 6.0 is such a sleepy release?

It's not a good thing for the Java community to release unnecessary major releases, because vendors have never been very good at upgrading to them.

From what I can tell, this is the breakdown of JDK usage based on our website (1.1M DTD resolutions from JVMs for the month of Jan 2006).

JDK 1.3 = 18% (~6 years old)
JDK 1.4 = 59% (~4 years old)
JDK 1.5 = 23% (~1 year old)

Furthermore, if Sun is still releasing J2EE +6months from J2SE releases, then are we going to see J2EE evolve as quickly? Where's the vendor commitment to support these new versions in a timely manner?

But most important of all....

Where are the features that will compete with C# 3.0, which not only kicks Java's tush, but also offers some serious competition for the dynamic languages.

    * Type inference (Implicitly typed local variables)
    * Duck typing (Anonymous types)
    * Extension methods (extension by simply using [importing])
    * Object and collection initializers
    * Lambda expressions (terse anonymous delegates)
    * Expression Trees (expressions as data)

Many of these language features were put in place to support Language Integrated Query (LINQ), which is probably the most innovative approach to ORM and multi-source data integration that I've ever seen.

I saw this stuff in action at PDC '05. It's unbelievable.

Why am I scared when I'm seeing Microsoft innovate more than the Java community? :-/

Cheers,
Clinton

I'm very afraid of adding more and more features to stable language as Java. I think that scripting languages, integrated with Java could give us all the goodies you mention. Won't adding all new things to core language change it into new PERL like lang?, unreadable for humans ;)
A word for LINQ - isn't it new SQLJ?

When I first saw LINQ, I thought "SQLJ" as well (or any number of inline SQL implementations).

But the answer is: no absolutely not. LINQ is far different from any other "inline SQL" solution -- in fact, it's not inline SQL at all.

First of all, LINQ isn't SQL. It's a generic Language Integrated Query. LINQ at its core is actually only useful for querying in-memory objects, particularly instances of IEnumerable<T>. It's an object based query language, more like HQL or ODMG.

The biggest difference is that it's native to the C# language, and more importantly, it's extendible.

C# 3.0 will include two extensions, one called DLINQ and the other called XLINQ, for relational databases and XML respectively.

The brilliant part of this is HOW they implemented it though. It's all done very cleanly (IMHO) through the use of the other language features I mentioned in my original post.

I was very skeptical, and I still am of the quality of the implementation when it's released. However, I was blown away by the concept and the quality of the innovation itself.

I'd really like to see features like this, but more importantly, innovation like this in future Java releases.

Cheers,
Clinton

Clinton,

 I looked at LINQ project at MS website. It is very interesting. it seems to me that if this project is implemented correctly, then it would boost the performance of an application that deals with huge in-memory objects. however, if I am given the choice, I will not allow such an extension to the native language syntax. I liked java because it is simple, and clean. Adding such syntax will make the language more complex. In Java, you can have the same functionality although coded differently by using external API. Innovation in Java should be happing outside the native language syntax. sun should be paying more attention to simplifying the current API rather than extending it.


I agree that GroupLayout should of been added to Java 6. but still, you can include the jar file ;-)

I'd like to point out LINQ is just re-inventing in-memory queries. Doing in memory queries has been around for over a decade. It's good that MS is doing that, but it's hardley new and definitely isn't breaking any ground. Gigaspaces already provides SQL-like query capabilities over a distributed data. JxTA has similar in-memory query capabilities. Tangosol's coherence likewise has some query capabilities.

I've only read a little bit of the documentation on MSDN on LINQ. From what I've read so far, I see no concrete data showing LINQ will work for large datasets in memory and perform complex queries efficiently. If you're aware of articles that suggest or indicate it may, then I would say LINQ is a strong feature to have. Until then, LINQ is just PR-ware that may never get released. Look at ObjectSpaces. Should Java immitate MS and waste a lot of time?

The business of Java shouldn't be to follow new trends or fads. Especially when there are applications that already provide equivalent functionality.

peter

Ok, you guys didn't look deep enough.

Yes, LINQ is in-memory queries...but you have to understand how it's implemented to appreciate it fully.

Furthermore, you have to look at DLINQ more specifically, not just LINQ.

DLINQ is NOT in-memory query. It's a full ORM build beneath the query API, like typesafe, inline, integrated HQL without all the string madness...

Don't get me wrong, I'm not asking for linq specifically in Java. I just want to see more innovation, which may not be language features. But I expect a +1 version of Java to have SOMETHING interesting.....Java 6 just looks boring.

Clinton

Ok, you guys didn't look deep enough.

Yes, LINQ is in-memory queries...but you have to understand how it's implemented to appreciate it fully.

Furthermore, you have to look at DLINQ more specifically, not just LINQ.

DLINQ is NOT in-memory query. It's a full ORM build beneath the query API, like typesafe, inline, integrated HQL without all the string madness...

Don't get me wrong, I'm not asking for linq specifically in Java. I just want to see more innovation, which may not be language features. But I expect a +1 version of Java to have SOMETHING interesting.....Java 6 just looks boring.

Clinton

I'm the furthest thing from an expert on LINQ, so it's likely I'm totally wrong, but I thought LINQ has very little to do with ORM. Looking at the examples, it's nice to be able query in-memory objects without having to use a specific query API, but I don't consider that good practice. For the same reason many people consider in-lining Java code in a JSP, native language query "could" lead to spaghetti code. Not that having the feature automatically leads to that, but my thought is this.

If the language has query capabilities built-in, and I'm under a tight deadline, it's easier to just sprinkle some queries here and there. Of course, I try NOT to do things like that, but sometimes those making the decisions don't care about organizing code and want it done yesterday.

Comparing LINQ to db4o, I like LINQ better

public void Linq9() {
    string[] words = { "aPPLE", "BlUeBeRrY", "cHeRry" };

    var upperLowerWords =
        from w in words
        select new {Upper = w.ToUpper(), Lower = w.ToLower()};

    foreach (var ul in upperLowerWords) {
        Console.WriteLine("Uppercase: {0}, Lowercase: {1}", ul.Upper, ul.Lower);
    }
}

db4o SODA, using C# [4]
Query query = database.Query();
query.Constrain(typeof(Student));
query.Descend("age").Constrain(20).Smaller();
IList students = query.Execute();

LINQ definitely has value, but whether Java should provide that natively is questionable to me. I'm sure there's hundreds of opinions on this topic. My bias 2 bits.

peter

I'm the furthest thing from an expert on LINQ, so it's likely I'm totally wrong

Sorry Peter, but yes you are completely wrong.

I think you missed the entire point of my post. But perhaps I was unclear. Let me try again.

Look at DLINQ -- with a "D".

READ THIS

Quote: "DLinq, a component of the LINQ Project, provides a run-time infrastructure for managing relational data as objects without giving up the ability to query. It does this by translating language integrated queries into SQL for execution by the database and then translating the tabular results back into objects you define. Your application is then free to manipulate the objects while DLinq stays in the background tracking your changes automatically."

Example:

      SqlConnection con = new SqlConnection( ... );
      con.Open();
      ...
      // DataContext takes a connection
      Northwind db = new Northwind(con);
      ...
      var q =
       from c in db.Customers
       where c.City == “London”
       select c;

Cheers!

Clinton

I'm the furthest thing from an expert on LINQ, so it's likely I'm totally wrong

Sorry Peter, but yes you are completely wrong.

I think you missed the entire point of my post. But perhaps I was unclear. Let me try again.

Look at DLINQ -- with a "D".

READ THIS

Quote: "DLinq, a component of the LINQ Project, provides a run-time infrastructure for managing relational data as objects without giving up the ability to query. It does this by translating language integrated queries into SQL for execution by the database and then translating the tabular results back into objects you define. Your application is then free to manipulate the objects while DLinq stays in the background tracking your changes automatically."

Example:

      SqlConnection con = new SqlConnection( ... );
      con.Open();
      ...
      // DataContext takes a connection
      Northwind db = new Northwind(con);
      ...
      var q =
       from c in db.Customers
       where c.City == “London”
       select c;

Cheers!

Clinton

Ahh, I missed that "D" part. Thanks for clearing that up. So there's 3 flavors of LINQ, but I think J2EE platform already provides equivalent functionality. Whether the query is native or SQL is a matter of preference to me. I'm still not convinced native query support needs to be at the Java language level. Stability is far more important to me than matching .NET feature for feature. There are plenty of things in .NET I like, but there are also plenty of things in .NET I hate. Same is true of Java.

peter

Whether the query is native or SQL is a matter of preference to me. I'm still not convinced native query support needs to be at the Java language level.

I am wondering how many new language keywords this kind of thing is going to introduce to C#? Is it going to break existing code if I try to compile old stuff under C# 3.0?

To me it seems too excessive, and unnecessary clutter in the language itself. This thing may seem nice now...until something much better comes along again; are they going to add that to the language as well? It is far easier to switch libraries than language features.

I am wondering how many new language keywords this kind of thing is going to introduce to C#? Is it going to break existing code if I try to compile old stuff under C# 3.0?

For the most part, the answer is no. C# 3.0 makes extensive use of pattern matching, so:

int from = 2;
int where = from * 2;
int select = from + where;

--and--

var q =
       from c in db.Customers
       where c.City == “London”
       select c;

Should not conflict, because from, where and select are only really keywords when used in that pattern.

That's to the best of my knowledge...you can confirm on Microsoft's website.

Clinton

I am wondering how many new language keywords this kind of thing is going to introduce to C#? Is it going to break existing code if I try to compile old stuff under C# 3.0?

For the most part, the answer is no. C# 3.0 makes extensive use of pattern matching, so:

int from = 2;
int where = from * 2;
int select = from + where;

--and--

var q =
       from c in db.Customers
       where c.City == “London”
       select c;

Should not conflict, because from, where and select are only really keywords when used in that pattern.

That's to the best of my knowledge...you can confirm on Microsoft's website.

Clinton

One intriguing part about in-memory queries like LINQ is how the query plan is generated. Speaking from a language compiler perspective, the syntax and grammar of the language has a material impact on compilation. Unlike SQL, native queries allow greater flexibility, but the trade off is query compiler complexity. How one compiles a query can mean 100x speed difference. In many cases, the query plan should be generated at runtime, while other cases it can be statically compiled with the class.

peter

One intriguing part about in-memory queries like LINQ is how the query plan is generated. Speaking from a language compiler perspective, the syntax and grammar of the language has a material impact on compilation. Unlike SQL, native queries allow greater flexibility, but the trade off is query compiler complexity. How one compiles a query can mean 100x speed difference. In many cases, the query plan should be generated at runtime, while other cases it can be statically compiled with the class.peter

Ted Neward did write a piece on comparing LINQ with contemporary art (including popular ORM tools like Hibernate). You can find it here:
LINQ Comparisons Article

Ted Neward did write a piece on comparing LINQ with contemporary art (including popular ORM tools like Hibernate). You can find it here:LINQ Comparisons article

Thanks for the link, but AFAICT, the article only talks about building a SQL query. That is completely different than compiling the query and creating an efficient plan. Ted Neward makes some interesting points, but I disagree that it's better. He may consider it better, but I definitely do not.

peter

Regarding java in-line SQL, be pros/cons of ORM versus rich and explicit SQL in the enterpise, LINQ. Of interest may be https://sqlb.dev.java.net/ . It is not for everyone but outstanding when it meets your requirement. We are looking for partners and peer review to grow and mature this library we have used for some time now.

I'm trying to evaluate SQLB for one of my projects but can't find it at the moment - looks like it has been moved from  https://sqlb.dev.java.net/ 

 

Do you know where it has gone? Is it still active?

Several Java tools have already been mentioned that are more or less similar to DLINQ. I'd like to point towards RIFE's object -oriented query builders though. Small example:

Select select = new Select(getDatasource())
    .from("friend")
    .fields(Friend.class)
    .where("firstname", "=", "John")
    .orderBy("firstname");
executeFetchAll(select, new DbRowProcessor() {
        public boolean processRow(ResultSet resultSet)
        throws SQLException
        {
            System.out.println(resultSet.getString("lastname"));
            return true;
        }
    });

Granted, this doesn't contain compile-time support for entity property names in the where statement, but besides that it's pretty close to what DLINQ seems to provide, without any Java language extension.

Just thought I'd throw this out here, you can find more information about RIFE here: http://rifers.org

Forgot to mention that it fully supports sub-queries, nested where statements, parametrized queries through prepared statements, etc etc

It isn't limited to Select either, there are similar query builders for CreateTable, DropTable, Insert, Update, Delete, ... and they translate automatically to the native SQL syntax of the targeted datasource.

You can have a look at JoSQL.

It has a similar syntax, like:
  // Get a list of java.io.File objects.
  List myObjs = getMyObjects ();
  Query q = new Query ();
  q.parse ("SELECT name,length " +
           "FROM java.io.File " +
           "WHERE fileExtension (name) = :fileExt " +
           "ORDER BY length DESC, name " +
           "EXECUTE ON RESULTS avg (:_allobjs, length) avgLength");
  // Set the bind variable "fileExt".
  q.setVariable ("fileExt", "java");
  // Execute the query.
  QueryResults qr = q.execute (myObjs);

I'm the furthest thing from an expert on LINQ, so it's likely I'm totally wrong, but I thought LINQ has very little to do with ORM.

After reading the document provided by Clinton, it looks like to me this thing is more like an implementation of Active Record, and not an ORM. It can't handle inheritation. Inheritation was stated to be a future consideration.

* Type inference (Implicitly typed local variables)&nbsp;&nbsp;&nbsp;&nbsp;* Duck typing (Anonymous types)&nbsp;&nbsp;&nbsp;&nbsp;* Extension methods (extension by simply using [importing])&nbsp;&nbsp;&nbsp;&nbsp;* Object and collection initializers&nbsp;&nbsp;&nbsp;&nbsp;* Lambda expressions (terse anonymous delegates)&nbsp;&nbsp;&nbsp;&nbsp;* Expression Trees (expressions as data)

From my point of view, all the features you have mentioned would only break the OO concept on which Java is based on.
C# is anything but OO, so this seems to me as an apple/oranges comparison.

You mean C# is just some kind of C-ish Basic?
Interesting.. need to think about =)

From my point of view, all the features you have mentioned would only break the OO concept on which Java is based on.C# is anything but OO, so this seems to me as an apple/oranges comparison.

To be fair Java is not purely OO language.

“Duck typing” concept is popular these days, but I do not like it in the Ruby sense.
“Duck typing” allows calling methods if they are present, but does not give hint what exactly do we need from an object

What I would love to see in Java is the dynamic casting to interfaces.
It should work like this:

inteface Appendable{
  void append( char c );
}


public void myMethod( Appendable a ){
  a.append('s');
}

and such method should take PrintStream and PrintWriter objects because they both have method 'append( char c)'

Surely you just need the Adapter pattern here?

[...]
What I would love to see in Java is the dynamic casting to interfaces.
It should work like this:

inteface Appendable{
&nbsp;&nbsp;void append( char c );
}

public void myMethod( Appendable a ){
&nbsp;&nbsp;a.append('s');
}

and such method should take PrintStream and PrintWriter objects because they both have method 'append( char c)'

Why, in the name of all that's holy, does anybody want to do this? Just because two methods have the same signature, does not neccessarily mean that the actually do the same. By explicitly implementing an interface, the implementing class indicates that it conforms to the contract defined by the interface. Allowing to push any object into a method, just because it accidentally defines a method with the same signature as the required interface is absolutely no good idea at all (IMHO).

Regards,
    Dirk

My Point exactly..

surely:

public class WriterAdapter implements Appendable {
   public WriterAdapter(Writer w) {
      this.writer = w;
   }

   public void append(char c) {
      this.writer.append(c);
   }
}



calling myMethod as:

myMethod(new WriterAdapter(System,out));

would work fine!

new Appendable () {
   void append(char c) {
      System.out.append(c);
   }
}
not so verbose.

My Point exactly..surely:public class WriterAdapter implements Appendable {&nbsp;&nbsp;&nbsp;public WriterAdapter(Writer w) {&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;this.writer = w;&nbsp;&nbsp;&nbsp;}&nbsp;&nbsp;&nbsp;public void append(char c) {&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;this.writer.append(c);&nbsp;&nbsp;&nbsp;}}calling myMethod as:myMethod(new WriterAdapter(System,out));would work fine!

Brilliant. But only expensive developer could write those code :)

[...]What I would love to see in Java is the dynamic casting to interfaces.It should work like this:inteface Appendable{&amp;nbsp;&amp;nbsp;void append( char c );}public void myMethod( Appendable a ){&amp;nbsp;&amp;nbsp;a.append('s');}and such method should take PrintStream and PrintWriter objects because they both have method 'append( char c)'

Why, in the name of all that's holy, does anybody want to do this? Just because two methods have the same signature, does not neccessarily mean that the actually do the same. By explicitly implementing an interface, the implementing class indicates that it conforms to the contract defined by the interface. Allowing to push any object into a method, just because it accidentally defines a method with the same signature as the required interface is absolutely no good idea at all (IMHO).Regards,&nbsp;&nbsp;&nbsp;&nbsp;Dirk

I agree completely. Ambiguity in the code creates maintenance and debuggging nightmares. Be explicit. Be precise. Good programming is not about saving the programmer key strokes. Typing code is not the most expensive or most important activity in development.

Ambiguity in the code creates maintenance and debuggging nightmares. Be explicit. Be precise. Good programming is not about saving the programmer key strokes. Typing code is not the most expensive or most important activity in development.

Hmm, RoR hype seems to suggest the contrary.

By the way that dynamic casting to the interface is supposed to provide the preciseness you are talking about.
In the realm of Ruby there is no way to know what body of a method needs from a parameter by looking at the method signature.
Sure adapters can be created, but ... less code is better.

Hmm, RoR hype seems to suggest the contrary.

Maybe, but what's the point?

By the way that dynamic casting to the interface is supposed to provide the preciseness you are talking about.

No it ain't. We are talking about _semantics_ not syntax, here.

In the realm of Ruby there is no way to know what body of a method needs from a parameter by looking at the method signature.

I don't understand that. Could you please elaborate?

Sure adapters can be created, but ... less code is better.

Sorry, I don't want to offend you, but I have to say this: That's among the most stupid statements, regarding SW development, I heared - I have to add that to my list.

Regards,
    Dirk

By the way that dynamic casting to the interface is supposed to provide the preciseness you are talking about.

No it ain't. We are talking about _semantics_ not syntax, here.

In the realm of Ruby there is no way to know what body of a method needs from a parameter by looking at the method signature.

I don't understand that. Could you please elaborate?When a method declares that it takes TypeA as a parameter is is pretty clear semantically as well as syntactically what we can supply to the method and what method can do with the given object;
Well it might actually do a weird cast to something else like this: public void a( TypeA a){
TypeB s =(TypeB) (Object)a;
}

However such insanity is rare, more often we see Object as a parameter and it gets casted to something else inside of the method body. So there is no sure way to know (without looking at source) what the method can accept.
Of course class and method names may suggest, and documentation may tell.... The same situation with Ruby – to the naked eye all the Ruby objects have type Object (at runtime they are strongly typed) and that lead to runtime surprises – we all love them, right? Of course we are supposed to have unit tests for everything. But you know, personally I hate to write tests for things which can be handled by compiler and/or refactoring tool much more reliably.

My idea of dynamic casting to interfaces implements Ruby's famous “duck typing”: if it walks like duck, quacks like duck, then it is a duck. Except that in Ruby nothing suggests that you need that object 'quack()' and 'walk()', well to some extend it is addressed by code availability.

With dynamic interface casting a method explicitly declares that object must 'quack()' and 'walk()'.

You are worried about semantic, well it is valid concern, however, even an object implements Quacker interface it might actually 'bark' .

Sure adapters can be created, but ... less code is better.

Sorry, I don't want to offend you, but I have to say this: That's among the most stupid statements, regarding SW development, I heared - I have to add that to my list.Regards, &nbsp;Dirk

Are you saying that more code with not quite clear syntax is better? Then it is for my list :)

Type inference is not "anti-OO", it's just "DRY" (don't repeat yourself). It's not always possible to infer the type for a given variable, but when it IS possible, the compiler should do it for you.

I'm not sure where you are coming from on this. My concern is too many changes and/or additions to the language syntax. I'd like to see more stability in the language. Of the features in your list of C# enhancements, only expression trees seems worth adding. Though I liked most of the additions made to Java in 1.5, I can't help but get the feeling that its becoming too gunked up. Really large languages are cumbersome - harder to learn, standardize and maintain. It is a major reason ADA never caught on.

I don't think that duck typing and other dynamic and weak typing language features are a good thing for a language targeting the enterprise space. I suggest that those who really benefit by those sorts of features are those working in the presentation space and maybe they should be using a different language, one better suited for that sort of programming.

I don't want to see Java get like XML where people are trying to make it all things to all people. It creates a lot of complexity and prevents it (Java or XML or whatever) from ever really being great at anything.

None of those features are critical to me and frankly, I see very little value adding those features for 95% of the applications out there. Anonymous types do seem useful to me for those writing very dynamic code, like scripting languages, but outside of that, I personally think it tends to lead to bad code. Not that the feature is inherently bad. In the hands of an experience and mature coder, I'm sure they are powerful. In the hands of a newbie or someone who thinks "it's neat", it usually leads to junk code.

I personally would wait and let the market show these features are a "net benefit" and isn't just a new fad. my bias 2 cents.

peter

.net and C# are generating a lot of enthusiasm, just look at all the heated discussions over at the sister site theserverside.net

.net and C# are generating a lot of enthusiasm, just look at all the heated discussions over at the sister site theserverside.net

I take it you are being sarcastic? :)

There has been twice as much Java discussion on theserverside.com since yesterday than there has been in .NET discussion on theserverside.net for over a month.

Yes, this should be called Java 5.1.

I agree w/ Clinton 110% on C#. Some of us develop in both, and it becomes interesting, as per his list.

I will also add that "Java 6" does not include the GroupLayout. (aka NetBeans Matise layout), as per Sun, becuase "it's too late to add it", even if Java 6 won't release until Q3 (in time for WinFX). Are we .... holding back? Can you think of a sweeter feature?!

I will say that adding SwingWorker is a big plus once "Java 6" becomes widley distributed to the user desktop (but then again C# had the "ThreadWorker" released year and avaialbe as a OS update for run time).

And another big minus, "javascript" is included? !!! Why? Why not depcreacate a bunch of things, omg packages come to mind. Look at Flash 8.5 run time even, w/ it's new VM (and that is cross platform, as is C#)


.V

ps: (Java 5.06 fixed WebStart big time, they moved that fix up from Java 6)

Note that Javascript is not included. Only the framework for scripting languages is included, as the original news post specifies.

I will also add that "Java 6" does not include the GroupLayout. (aka NetBeans Matise layout), as per Sun, becuase "it's too late to add it", even if Java 6 won't release until Q3 (in time for WinFX).

I will agree that the lack of this layout in Java 6 is truly a shame.

And another big minus, "javascript" is included? !!! Why? Why not depcreacate a bunch of things, omg packages come to mind.

JavaScript uses scopes instead of packages. For example, I can define two functions with the same name without fear of name collision like so:

<code>
var thisScope = {}
thisScope.name = function() { return "thisScope"; }

var thatScope = {}
thatScope.name = function() { return "thatScope"; }
</code>

actually javascript behaves differently
for example

{
   var c = 1;
   c++;
}

this is a real "scope"
but here..

var g = {};
g.prop = { a : 1, b : 2 };

that is called "object literal" or associative massive(read "object" in JS) initialization. And actually this feature
is similar to C#'s anonymous initializers (?)
 new { a = 1, b =2 };

How is it that this:

{
  var c = 1;
  c++;
}

is no longer a "scope" if it's assigned to a reference?

var a = {
  var c = 1;
  c++;
}

Or this:

I don't see the distinction you're trying to make. Why are they mutually exclusive of one another? Perhaps I'm using the term scope too loosely for your tastes? Please explain.

James Tikalsky

Sun/JCP can't be serious. This is hardly a major upgrade and seems rushed.

You know, I think the basic "problem" is that Java has been so successful and is now so broadly used in enterprise applications that both Sun and the Java community have become conservative. C# is still the underdog and MS is taking a much more aggressive/innovative approach in adding new features. MS has also hired many bright minds from the functional programming / Haskell community and is letting them apply their ideas to C#. LINQ and Software Transactional Memory are two excellent examples of that. In the Java space, innovation happens (mostly) in third-party libraries and C# does not even come close in that respect.
So, I think you should expect J2SE/J2EE to evolve slowly and rather conservatively. If you're looking for excitement at the language level (and there's nothing wrong with that of course), you'll probably want to look elsewhere as 99% of the community is most likely to agree with Sun on this one...

Sun/JCP can't be serious. This is hardly a major upgrade and seems rushed...Where are the features that will compete with C# 3.0, which not only kicks Java's tush, but also offers some serious competition for the dynamic languages.&nbsp;&nbsp;&nbsp;&nbsp;* Type inference (Implicitly typed local variables)&nbsp;&nbsp;&nbsp;&nbsp;* Duck typing (Anonymous types)&nbsp;&nbsp;&nbsp;&nbsp;* Extension methods (extension by simply using [importing])&nbsp;&nbsp;&nbsp;&nbsp;* Object and collection initializers&nbsp;&nbsp;&nbsp;&nbsp;* Lambda expressions (terse anonymous delegates)&nbsp;&nbsp;&nbsp;&nbsp;* Expression Trees (expressions as data)

It does not look like a major update and maybe 6.0 is too much. It is hardly rushed if it is not a major update. Yet, you would be rushing all kinds of features to Java because C# is doing it???

More and more features are pushed to it (C#), and it starts to look like a bad action sequel with more explosions and special effects. I doubt it will sell.

If the language features being added to C# are so compelling, maybe what's need is a C#->Java Bytecode compiler.

Note that I'm not advocating porting all the C# libraries to Java. There's a difference between a language and it's standard libraries. But I think a C# compiler for the JVM could be very interesting.

If the language features being added to C# are so compelling, maybe what's need is a C#->Java Bytecode compiler.Note that I'm not advocating porting all the C# libraries to Java. There's a difference between a language and it's standard libraries. But I think a C# compiler for the JVM could be very interesting.

There might be some edge cases where translation might be a bit tricky or aweful, but assuming it's pure C#/CLR code, it should be feasible. There's already IKVM for running Java on .NET CLR.

peter

Also see Visual Grasshopper. I seem to recall an actual port of C# to the JVM from sourceforge a long time ago, but I can't remember what it was called or if it's a viable implementation (and SF doesn't show anything for it from fairly casual searches, so maybe I'm mistaken about it.)

I have solved this problem having developed JNI for .NET as regular one for C++. See free library at http://www.simtel.net/product.php[id]95126[SiteID]simtel.net and examples, which show how easy Java code integrated with .NET language, how easy to embed Java GUI to .NET and .NET GUI to Java code without mediators like COM, CORBA, SOAP, etc.

Sun/JCP can't be serious. This is hardly a major upgrade and seems rushed. Looking at the major enhancements 1.4 and 5.0 brought, I wonder why 6.0 is such a sleepy release?

I believe this is an effort to avoid big earth shaking releases like 5.0 and go to a more regularly scheduled pace of incremental improvements. Given a more traditional numbering scheme, this would typically be called 5.0. But I think that Sun is trying to stay away from minor releases so they are calling it 6.0.

This is probably a good thing. Enterprises and OEMs can't digest releases faster than one every 18 months. But if we wait longer than a couple of years between releases then the chasm between the releases gets too large. (Both in features and in the challenges of upgrades.)

Sun/JCP can't be serious. This is hardly a major upgrade and seems rushed.

More does not mean better! It's important that Sun add only what they're sure adds value to the whole. I think Sun did a good job with Java 5 of adding a lot but making sure that everything that added was actually a good addition. [While the new for loop may be considered unnecessary syntactice sugar, it's not really harmful.]

I'd argue that their release is not rushed. The feature set has been known for some time. They've exposed this to developers to find issues and give feedback early in the process, so this should be a much more solid release in some respects (e.g. in terms of the feature fit to reality, for example, where I know Sun has changed API details in reponse to feedback).

Sun has publicly stated they're going to have regular ~18 month releases that are less earthshattering to upgrade to -- and I think that's a great plan. Giant steps are a bad thing for everybody. They inherently become infrequent and have unpredictable timing. They also can easily become a disruption to development. Small changes can be made regularly and more frequently and can be more easily digested by the development community.

Where are the features that will compete with C# 3.0, which not only kicks Java's tush, but also offers some serious competition for the dynamic languages.

I personally applaud Sun for not adding this stuff. I've read the C# language additions documents, and I'd be horrified if Sun added this stuff to Java. The C# additions are well and good if you're a 1-3 person development team. In a larger team they'll make others' code a magical, unreadable, incomprehensible and overall unmaintainable mess. There are already enough complaints about Java 5's language/grammar complexity. Adding this stuff would make it worse than C++ ever was.

C and even C++'s mantra has been to try to solve problems via standard libraries rather than expanding the language. That should and has been Java's approach as well. When really necessary, add to the language, but try not to as it then raises the learning curve and barrier to entry for everyone.

Just because Microsoft adds marketeering features to C# and makes their language an ugly mutt does not mean Sun should do the same!

Why am I scared when I'm seeing Microsoft innovate more than the Java community? :-/Cheers,Clinton

.Net has to work and i am affraid that it doesn't on crucial moments. Microsoft stuff comes with a lot of bugs useally. I am actually ready to switch because java feels so heavy that my stomach hurts but I am once bitten twice shy. Does one also have to start up the server the whole f*g day for every code change on the .Net platform?

Sun/JCP can't be serious. This is hardly a major upgrade and seems rushed. Looking at the major enhancements 1.4 and 5.0 brought, I wonder why 6.0 is such a sleepy release? It's not a good thing for the Java community to release unnecessary major releases, because vendors have never been very good at upgrading to them. From what I can tell, this is the breakdown of JDK usage based on our website (1.1M DTD resolutions from JVMs for the month of Jan 2006).JDK 1.3 = 18% (~6 years old)JDK 1.4 = 59% (~4 years old)JDK 1.5 = 23% (~1 year old)Furthermore, if Sun is still releasing J2EE +6months from J2SE releases, then are we going to see J2EE evolve as quickly? Where's the vendor commitment to support these new versions in a timely manner?But most important of all....Where are the features that will compete with C# 3.0, which not only kicks Java's tush, but also offers some serious competition for the dynamic languages.&nbsp;&nbsp;&nbsp;&nbsp;* Type inference (Implicitly typed local variables)&nbsp;&nbsp;&nbsp;&nbsp;* Duck typing (Anonymous types)&nbsp;&nbsp;&nbsp;&nbsp;* Extension methods (extension by simply using [importing])&nbsp;&nbsp;&nbsp;&nbsp;* Object and collection initializers&nbsp;&nbsp;&nbsp;&nbsp;* Lambda expressions (terse anonymous delegates)&nbsp;&nbsp;&nbsp;&nbsp;* Expression Trees (expressions as data)Many of these language features were put in place to support Language Integrated Query (LINQ), which is probably the most innovative approach to ORM and multi-source data integration that I've ever seen.I saw this stuff in action at PDC '05. It's unbelievable.Why am I scared when I'm seeing Microsoft innovate more than the Java community? :-/Cheers,Clinton

I know this is still beta, but running my standard simple JGroups benchmark (http://wiki.jboss.org/wiki/Wiki.jsp?page=PerfTests) on a 100Mbps swi, I got

- for JDK 5: 11050 1K msgs/sec
- for JDK 6: 8850 1K msgs/sec

This is almost 30% slower. I used the same Windows XP Pro laptop, and the same options:
-Xmx100M -Xms100M -XX:NewRatio=5 -XX:+AggressiveHeap -XX:ThreadStackSize=32 -XX:CompileThreshold=100

What's going on ?

Bela Ban

It's such a shame that they did not include Sockets Direct Protocol as they had originally planned ..

Guglielmo

Enjoy the Fastest Known Reliable Multicast Protocol with Total Ordering

.. or the World's First Pure-Java Terminal Driver

distinct improvements over previous JVMs being a goal

that ought to be something as it seems/reads like the current vm performs bueno to quite bueno. we were really pleased with the performance improvements in a number of our apps under load test with the new vm versus the previous rev.

Before i get flamed, I better say that i have been developing in Java since it was launched and i am a pretty strong advocate for java especially in the enterprise applications arena... Don't really feel that .NET is able to perform the functions as well...

However, in my opinion, several aspects of .NET do seem attractive having developed in .NET for the past one year or so (I still do a fair bit of J2EE)

1. Delegates - Too often I have had to come up with interfaces just so as to allow the various components to talk to each other. Even launching a thread required implementing a runnable anonymous class to be able to support the function. I do like the ability of saying "new Thread(new ThreadStart(MyMethod)).Start()" to create and launch threads from .NET. While i suppose this can be achieved by implementing a Runnable that uses reflection to invoke a method, i find the .NET approach cleaner.

2. Events - Growing from delegates is the ability to create events. I hated having to create anonymous listeners all over the place especially when doing swing applications. Furthermore... adding and removing listeners is irritating (not difficult... just irritating). So now, instead of doing

component.addMouseListener(new MouseAdapter() { onMouseClicked(MouseEvent e) {...})

I can just do

component.OnMouseClicked += new EventHandler(someMethod) and allow the framework or the individual classes to invoke the necessary methods.

Just my 2 cents
Jega

I absolutely agree - delegates are really great and it's shame they are not in Java.

Oracle is buying the folks at InnoDB, Sleepycat and potentially buying JBoss and Zend. Oracle isn't buying the know-how, they are trying to control it or kill it.

Who thinks Java should be open sourced? Who thinks if Java was open source Oracle would not try to control it.

I still have had no chance to use java 5 in anger. We are not planning to use it here anytime soon, and I can understand that, since even the latest websphere 6 runs on java 1.4. Even the small web-hosting provider I am using is still running tomcat 4 and not even thinking of upgrading...

Thus, I have only had a limited exposure to java 5 - just played with it, really.

So I wonder if I should skip a level and go straight to learning java 6. Will I miss something? I think most organisations will do the same and wait for java 6 now that it's in the pipeline....