Slashdot Mirror

First - I want to see in the license where it requires them to pull it
off systems.

This was followable via the links in the original article.

Oracle has ended the DLJ, the "Distributor License for Java".
http://jdk-distros.java.net/
http://robilad.livejournal.com/90792.html

Second - What the hell are they going to replace it with? Are they saying
you have to download and install Java manually? OpenJDK
supposedly doesn't work with all things.

That's true; there are certain known issues with OpenJDK and basically Oracle is saying "it'll just have to do".

Third - What does this mean for Ubuntu derivatives like Mint? Are they
going to have to pull the jdk as well?

Yes, and that's exactly what's been happening, because there's no other choice.

uh, not sure if you even read the original article but..

There IS an open implementation of java, the openJDK, which is why this is being shut down (IBM who was the main contributor to Harmony has moved it's resources to openJDK).

openjdk may be "open" but it comes with field of use restrictions, restricting its "openness".

uh, not sure if you even read the original article but..

There IS an open implementation of java, the openJDK, which is why this is being shut down (IBM who was the main contributor to Harmony has moved it's resources to openJDK).

But I guess it's more in line with slashdots javahate if we ignore those facts.

OpenJDK is thriving http://openjdk.java.net/projects/jdk7/ so its just a matter of time basically.

FYI - I'm the London JUG co-leader, we have a seat on the Java Standards Body (aka the JCP) and I've seen first hand the Oracle and Java community challenges :-).

I think Oracle's record with the Java community is turning around in the right direction. They clearly didn't know how to the deal with the community to begin with, but I'll give em credit for trying their damnedest to get better at it! For example:

• They offer amazing amounts of (no strings attached) support to the Java User Groups (we've certainly had it better than we did under Sun). They put their $/£ where their mouth is and offer logistical support for user group events to boot (again, no strings attached).
• They set a date for Java 7, and they delivered the darn thing.
• They're working on the JCP reforms, starting with openness and transparency (JSR-348) and they will have a follow-up JSR to address all of the legal/licensing etc concerns (promises to be a humdinger of a mailing list).
• They've gotten a number of major community players into the OpenJDK (some will argue dubiously, but hey having Apple, SAP, IBM, RedHat on board is not to be sneezed at).

Now before the sceptics spit out their coffee:

• Have they screwed up a bunch of times? Yeah sure they have, Hudson/Jenkins, the Java Web Start thing and a few others.
• Do they communicate in a way that the community would like them to? Definitely not always, they like to keep silent until they get the official ducks in a row.
• Are there issues around legal/licensing? Heck yes. and that's going to make for an interesting 2012, I suggest you become part of the JCP process so you can have your say.

So there's definitely stuff to work on, but they are listening and the community has worked with them on many occasions in the past year to get some really cool things done. Let's not forget they're mainly individual engineers like you and I trying to do the very best they can for the platform.

Now I'm off to put on my Kevlar ;-)

I don't use Java3D but if you look at the jnlp file at http://download.java.net/media/java3d/webstart/release/java3d-latest.jnlp you can see how native libraries are included depending on os:

I don't like oracle either. But if you are writing a webstartable application, you probably have the infrastructure to sign your own jars. So you could sign the Java3D-jars yourself and distribute them together with your application. Depending on availability of something like http://download.java.net/media/java3d/webstart/release/j3d/1.5.2/windows-i586/j3dcore-d3d_dll.jar - signed or not - isn't really advisable anyway.

I never heard of that particular example and trying "true == new Boolean(false)" always evaluates to false in a console.

That's why I mentioned a conditional expression. Try:

if (new Boolean(false)) document.write("epic fail");

As for the rest of it, the key word in all your replies is "will". Yes, I know a lot of it is being treated for EcmaScript vNext, but we're talking about what's available for use today (and, realistically, one can't just stick to Mozilla alone and use their extensions - we'll have to wait for the standard, at least for an implementable draft, and then for browsers to pick it up). And today, these are are still issues - the fact that changes are considered for the next language version is a proof of that.

The other problem is that, even once the changes are there, existing semantics would still remain for the sake of back-compat, and will provide a source of perpetual confusion for newcomers, and plenty of opportunity to write bad code. I'd expect most people to pick "var" over "let" for declaring variables, for example, just because "var" is the more obvious construct. And then they'll run into scoping issues, esp. with lambdas...

It's the exact same problem that C++ is facing. Most of the recent (STL and after) additions are good, but there's lots of old cruft there dating back to ARM C++ and K&R C. And they can't just throw it out of the language.

Maybe they need to come up with some kind of "use sanity" mode to build on the existing "use strict", that would kill all existing garbage in the language. Then we could set a simple regex commit filter to check that it's always there, and call it a day.

Personally, I love arrow functions.

Given that Oracle has just settled on using arrow syntax for their lambdas in Java 8, I hope that JS will follow. That way we'll at least get some syntactic unification over curly-braces family, what with C#, Scala and C++ all using arrow for that already.

That was one of the questions I wanted to ask. So how open (source) is it now ?

I just know OpenJDK exists, I even know where to download it:
http://download.java.net/openjdk/jdk7/

The problem here is that mixing different languages is a bit difficult. It would be great if you could do UI stuff in some high-level language like Java, C# or VB and do the heavy problem-solving stuff in ASM, C/C++ or Fortran.

Spot on! The very reason I started to learn Java about 12 years ago: the UI stuff. Boy, even now I can't be bothered again with MFC or widgets.

It's not impossible to mix languages, but it's certainly not made easy.

For my own experience: JNI takes about 1-2 days to understand and 1-2 months to adjust your mind and habits in using it. I'd say, not that hard either. (see also JNA)

Version 6 Update 23 is due to be released soon, it is already at beta 3.

http://jdk6.java.net/6uNea.html

Oracle has a detailed list of the additions in Java 7. OpenJDK has relatively the same information listed in a different way.

While it took forever to get JDK7 out the door, it's finally out and they can work toward JDK8, which is currently scheduled for release a year from now. The Oracle takeover is said and done and they are able to keep pushing new features into the language now. For all of us that use Java daily, this is a nice change.

I recommend looking over the feature list if you are a java dev. There are some really nice changes to make your day-to-day code just a little easier.

Funny enough, I just set up an Ubuntu box and decided to grab JDK 7 without knowing that today would be the day it was "released". As such, I downloaded it directly from Oracle/Sun/Java/Whatever..

Note, I then installed Eclipse Indigo, which was having some problems with some of the plugins. I added the following line to the eclipse.ini file and the problems went away:

-Djava.util.Arrays.useLegacyMergeSort=true

Everything's working fine now.

and not even supported under Oracle's current Type-1 Hypervisor Oracle VM 2.2

http://jdk7.java.net/JDK7SupportedSystemConfigurations.html - note this:
All supported platforms are supported when virtualized in a supported hypervisor
Supported hypervisors are: Oracle VM 3.x, VirtualBox 3.x, 4.x, Solaris Containers and Solaris LDOMs. Except where noted.
VMWare and Microsoft Hypervisor NOT supported

I wrote up a blog article on this and the repercussions for paying Oracle customers of things like Oracle E-Business Suite that utilize Java
http://weinshenker.net/blog/2011/07/28/oracle-playing-fair-vmware/

Project lambda was arguably the most important planned addition to the JDK7, but apparently got dropped in the last few months and pushed back to JDK8. To be honest Project Coin, Fork/Join, and InvokeDynamic are useful, but not much of a big deal as Project Lambda.

Project lambda was arguably the most important planned addition to the JDK7, but apparently got dropped in the last few months and pushed back to JDK8. To be honest Project Coin, Fork/Join, and InvokeDynamic are useful, but not much of a big deal as Project Lambda.

You make no sense. Android is a much more open platform than Oracle-owned Java will ever be.

Except when the company refuses to give us the source code.

With JavaSE, I can get the source code to the current Java version at any time, under the GPLv2 license from the Mercurial repository on the OpenJDK site. It's JavaME that's the problem there, because it's intentionally being withheld.

(JavaEE is being ignored here, as it's just a set of standards that has about 10 different implementations, half of which are open source).

It's unfortunate that Schwartz's blog is gone, and that ZDNet didn't drill down a little more carefully to check dates on things. I was working with Sun on the java.net site at the time, through a contract with O'Reilly. As I recall, the story is actually somewhat worse. The rumor mill reported that Android would be using Java, and Schwartz went off half-cocked and praised Google for the "Java/Linux platform". Writing for java.net, I said "But I didn't end up putting this on the front page, because I just couldn't source the Java angle well enough (no offense, Jonathan, but you did say ZFS would be on Leopard...)." (that's the current editor's headshot on the page, not me, BTW).

Not too much later, Google laid out the details of Android, including the Dalvik VM, which meant that Google was only using Java the language (which it didn't have to license) and not Java the VM (which it would have had to). What I heard through the back channel was that Sun was pissed, believing it had been stabbed in the back. This made for a very awkward scene at Sun's mobile-focused "ME Developer Days" a few months later in January 2008: the Sun people had clearly been told to not talk about Android or acknowledge it in any way, which led of a few awkward moments of dancing around the elephant in the room. The first night of the conference, the Java Posse stopped by for dinner, and upon seeing Dick Wall (who at that time worked at Google), the first thing I said to him was "man, are they pissed at you guys."

Relevant dates and links:

• November 5, 2007 - Google announces Android, doesn't mention Java
• November 5, 2007 - Later that day, Schwartz posts blog praising Android as "Java/Linux platform"
• November 12, 2007 - First release of Android source, Dalvik revealed. This blog, written that day, has a pretty good explanation of the fast one Google pulled on Sun. "How did Google manage to get Sun to license off a platform that could very well kill their own? Turns out, they didn’t: their move was even smarter than Sun’s."

Anyways, assuming my recollection of events and this timeline is accurate, Schwartz's blog should not be taken as an indication that Sun knew about and approved what Google was doing with Android. What it does prove is what a lot of people knew then but wouldn't say: Schwartz was a clueless loud-mouthed buffoon who happily fiddled away on his blog as SUNW burned.

The equivalent language feature for Java is part of Project Coin, and is coming in Java 7.

Hmmm... I don't think it's that simple.

As far as I understand, you can download and change OpenJDK (it's GPL v2), but if you want to distribute your version without fear of being sued for patent infringement, you must make sure your own version (i.e., OpenJDK plus you changes) passes the TCK -- that is, you must prove to Oracle that it's really "Java", and not some other language that's slightly incompatible with it.

TCK, of course, is not open. When you ask Oracle for the TCK, they want to know what you will do with it (see here), and they are free to deny it or put any restrictions they want on it.

The Jenkins fork essentially made this a non-event. Here at work we have been using Hudson on Ubuntu. After an apt-get upgrade, Hudson is now Jenkins on our system. The only pain point was the change from /var/lib/hudson to /var/lib/jenkins.

Oracle needs to learn that in the Java world, communities and personalities matter more than corporate branding. Most don't know Hudson as the CI project from Sun, they know it as the easy to use CI project created by Kohsuke Kawaguchi while working at Sun. Java itself was created by this guy named James Gosling. Guess what? Both left Sun/Oracle after Oracle took the reins. The battle over Hudson was about brand. Oracle was loosing the battle because they were loosing the people. That is where much of the brand equity lies.

In standard usage, saying X is a Y language refers to the canonical implementation of X. So Python is an interpreted language means CPython is interpreted, and doesn't refer to any of the experimental JIT versions.The Python that everyone actually uses is an interpreter that works with an intermediate bytecode representation. The Java everyone has uses a just in time compiler. The difference is kind of hazy sometimes, but there is enough of one to talk meaningfully about Python being interpreted and Java being compiled. (http://en.wikipedia.org/wiki/Interpreter_(computing))

I say that in "standard usage," a compiled language is one whose implementation produces an executable, native code file. By that definition, Java is not a compiled language (unless you use GCJ or another non-canonical native code compiler). Which standard are you using?

If you want to say that an "interpreted language" is distinct from a "compiled language," where does that leave Java? Most implementations involve both compilers and interpreters. The most commonly used implementations currently use Java byte code interpreters, with JIT compilers that generate native code from some of the byte code. They are completely functional with the JIT turned off, but can't do anything without their interpreters. While it is useful to describe a language implementation as using a JIT compiler, to simply call it a "compiled language" is not, since an increasingly overwhelming majority of source code is compiled at some point.

Since you mention "canonical implementation," what is the canonical implementation of Java? Is it whatever you can download from Oracle at the moment, OpenJDK, IcedTea, whatever comes with your OS, or something else? The early releases of Java from Sun did not have a JIT compiler. Did Java suddenly transform from being an "interpreted language" to a "compiled language" when Sun started including the HotSpot JIT compiler?

Don't forget to read to the bottom of that PyPy blog article. PyPy is certainly an impressive tool, but you can get a big improvement with something like Cython that lets you give the translator hints. The actual benchmarks:

CPython: 59.593 s
PyPy: 8.947 s
Cython: 3.5 s after adding a few types

Adding a few types in Cython means statically typing a few heavily used variables. His other (approx. 26 s) result with Cython I can only assume involved just Cythoning his straight Python code, which isn't really what Cython is supposed to do. The beautiful part of Cython is that you CAN give it straight Python code, or straight C code, or anything you want in between.

Yes, Cython clearly does have great advantages in speed over pure Python code and I shouldn't have implied that it didn't. I certainly will consider using it if I find some Python code that's running too slowly. However, that blog post also didn't compare an implementation in RPython, PyPy's Python-like language which also executes much faster than full Python.

I did a line count on this file, which includes all the java source file processing tools: javac, javah, javadoc. Since they share a lot of code (the front end is the same), I can't tell the proportionality of the javac code in there.

Disclosure: The author is my son, so yeah - proud Dad talking, but seriously check his work out for yourself if you (like me) think the review leaves something to be desired. Personally I'm still reading the book, so can't evaluate yet...

Better than merely reducing the attack surface of the platform by not including Java, Apple has also begun working with Oracle/Sun and contributed to OpenJDK. This should provide more timely updates to folk using Java on Mac OS X.

Far be it for anyone to question you, Mr Sr. Director, but one of the advantages of this open source stuff is that people can fact-check you pretty easily. So I did.

The OpenDS change log is at http://java.net/projects/opends/sources/svn/history?page=1&theme=java.net and while there have indeed been a bunch of updates made, they all seemed to dry up about two months ago (apart from a lone update made this week).

The OpenDJ change log is at http://sources.forgerock.org/changelog/opendj/ and it seems to me that it is being actively maintained at the moment.

So while I am sure your words read precisely are factually correct (work has happened since last February), they don't seem to me to recognize the actual situation (nothing much has happened this year). To my eyes, it looks like the Forgerock people are increasing their engagement with the code, while your people have given up. And the only real FUD I can find doing searches is you saying the OpenDJ project is a bad thing because, well, forks are always bad, right. Unless I've found the wrong OpenDS and OpenDJ logs - I've never looked at either before so I may have it all wrong I suppose.

So. This "next level" you speak about. Is it a level with locked doors that none of us can get into to fact-check you?

Ah, but you forget OpenJDK is released under GPL2 which comes with a patent grant. http://openjdk.java.net/legal/gplv2+ce.html

Oracle trashed a lot of former Sun technologies â" not the least of which is Sun's open source identity platform which included OpenSSO and OpenDS.

Uh.. I don't get it. Oracle still sells these, the DS anyway, maybe Sun's SSO was tossed, but Oracle had their own identity platform too. It's surprising enough that Sun's DS is still available and prominently listed.
http://www.oracle.com/technetwork/middleware/id-mgmt/overview/index-085178.html?ssSourceSiteId=ocomen

And, the corresponding open source projects are still here http://www.opends.org/ and here http://java.net/projects/opensso

Is this a silly way to say Oracle is not commercializing Sun's open source versions of the projects Oracle _owns_ and is selling? Isn't that kind of good for open source? I would think more distance between Oracle and OpenDS/OpenSSO would be a GOOD thing for the health of the open source projects?

Oh.. this is a slashvertisement, shit, and I fell for it.

...this has not anything to do with Looking Glass does it?

Um, no. Just as it has nothing to do with the Looking Glass UNIX desktop environment http://books.google.com/books?id=IToEAAAAMBAJ&pg=PT32&lpg=PT32&dq=looking+glass+unix+windowing+environment&source=bl&ots=UbkbO-iHYP&sig=KqYl5AMLJDpTjO0KYZsj0Woq1R4&hl=en&ei=XUkaTfaBC4bCsAOnjOGSCg&sa=X&oi=book_result&ct=result&resnum=3&ved=0CCQQ6AEwAg#v=onepage&q=looking%20glass%20unix%20windowing%20environment&f=false or the DHARMA Initiative station of the same name ...

...this has not anything to do with Looking Glass does it?
The project seemed to me worth of interest back then.

Nope, you're not forced to release under the GPLv2. What you are forced to do is put field-of-use restrictions on your implementation. Field-of-use restrictions are fundamentally incompatible with Open Source, and particularly incompatible with the GPL and other copyleft licenses.

Seems to me, you're splitting hairs. Technically, GPLv2 requires that any code you release must not put further restrictions on your license beyond that of the GPLv2 - tanamount to saying you must release your code under GPLv2 or a compatible license.

This is directly from section 2b of the GPLv2 license for OpenJDK
b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
(bolding mine).

This can be found at
http://openjdk.java.net/legal/gplv2+ce.html

Rather than attempt to rehash the details in this post (which usually leads to misstatements, which lead to further objections from readers, and so on and on), one of the previous posts provided a link which, I believe, gives a fairly straightforward, easy to understand treatment of the topic.

http://skife.org/java/jcp/2010/12/07/the-tck-trap.html

The TCK is closed source.

Actually, you're partially correct. The TCK consists of three parts - the JT Harness, SigTest and the Spec Trac Tool. The JT Harness and SigTest are open source - both licensed under GPLv2.
https://jtharness.dev.java.net/ and https://sigtest.dev.java.net/

Only the Spec Trac Tool is closed source and available only to JCP members. Of course, this is sort of a mute point since all three TCK components are needed to pass the compatibility test. However, it is an important point lest one get the impression that Oracle simply wants to protect their proprietary TCK, when a good portion of it was contributed by the open source community. It is interesting however that Sun obtained the patents in question (not Oracle) and never tried to enforce them against Google, then Oracle comes along, buys Sun and immediately goes after Google. Some might think that puts Oracle in the unsavory position of being a patent troll. Oracle's current stance on dropping the field-of-use restrictions is inconsistent with their stance a couple of years ago when they supported Apache's request to Sun to have them lifted.

Also,

only available under the condition that you don't release your clean-room implementation of Java as open source

is not quite true. In fact, if you do develop a clean-room implementation (and assuming you were able to get TCK certification) you are forced to (via the terms of GPLv2) release your implementation under the GPLv2 license. This is where Harmony has a problem. Their (Apache) license is not compatible with GPLv2.

The TCK is closed source.

Actually, you're partially correct. The TCK consists of three parts - the JT Harness, SigTest and the Spec Trac Tool. The JT Harness and SigTest are open source - both licensed under GPLv2.
https://jtharness.dev.java.net/ and https://sigtest.dev.java.net/

Only the Spec Trac Tool is closed source and available only to JCP members. Of course, this is sort of a mute point since all three TCK components are needed to pass the compatibility test. However, it is an important point lest one get the impression that Oracle simply wants to protect their proprietary TCK, when a good portion of it was contributed by the open source community. It is interesting however that Sun obtained the patents in question (not Oracle) and never tried to enforce them against Google, then Oracle comes along, buys Sun and immediately goes after Google. Some might think that puts Oracle in the unsavory position of being a patent troll. Oracle's current stance on dropping the field-of-use restrictions is inconsistent with their stance a couple of years ago when they supported Apache's request to Sun to have them lifted.

Also,

only available under the condition that you don't release your clean-room implementation of Java as open source

is not quite true. In fact, if you do develop a clean-room implementation (and assuming you were able to get TCK certification) you are forced to (via the terms of GPLv2) release your implementation under the GPLv2 license. This is where Harmony has a problem. Their (Apache) license is not compatible with GPLv2.

For starters, to provide some context, here is the current text of Project Lambda proposal - it's a fairly short and readable document explaining both syntax and semantics. Here is the mailing list.

Project Lambda. The proposed syntax needs to be more Java-like.

There's a load of issues with semantics as well. They carried over a bunch of limitations from anonymous inner classes, such as inability to capture mutable locals (though at least you don't have to slap "final" on everything now, that will be inferred) - so it's still not true closures.

I was also rather disappointed by the way community input was handled in Project Lambda. Originally, it was unclear why they started it from scratch when there were as many as 3 major proposals for lambdas already (BCGA, CICE, FCM) which could be used as a base. The original claim was that community is too divided on those, and so a "clean slate" effort, guided by feedback of all interested parties, would reach a more universally accepted solution. What happened instead is that, after a lot of discussion on syntax and semantics, Sun - er, Oracle - just published their own spec and started to implement it right away. Pretty much all feedback on that was either quietly ignored, or disregarded under various reasons. This concerns both syntax and semantics.

With syntax it was especially disconcerting. Originally, there was a lot of discussion focusing on syntax on the mailing list, so Sun/Oracle folks declared a moratorium on it, saying that it's "not so important" and that "we can discuss it later", after semantics are figured out. Since then, their proposals have had a major unilateral revision of syntax, and that is seemingly final for the proposal given that it's what they plan to submit for JCP. So the syntax was effectively not discussed at all in any way that made a difference, even officially.

The only case of feedback on semantics seemingly making any difference was with respect to lexical scoping of identifiers in the lambda. Consider this code:

abstract class SamType {
int foo;
abstract int bar(int x);
}

class Test {
int foo = 123;
void baz() {
SamType f = #{ int x -> x + this.foo };
}
}

The question at hand was about what "this.foo" in the lambda body is supposed to mean. The original Sun/Oracle proposal wanted to have the same rules as for anonymous inner classes; in this case, since the lambda is an instance of SamType, this would mean resolving "foo" to SamType#foo on the lambda itself, and you had to write "this.Test.foo" to get the other one - again, same as with AICs. After a lot of negativity on the mailing list, they've changed it to use strictly lexical scoping - so "this.foo" now refers to Test#foo.

However, even in that case the attitude was interesting - when discussion started on the mailing list, Sun employees were quite dismissive of any criticism, and their response pretty much boiled down to "we believe users who're used to AICs will want lambdas to behave the same". Then suddenly they release a new spec with updated semantics, and no comments as to why they changed it, disregarding their own past arguments in favor of the old one.

So, as far as "community participation" goes, I'd say that Project Lambda has largely been a failure so far. We'll see if it favors any better in JCP.

As to its technical merits - we'll see when it gets released, but if this happens in its present shape, then I'm afraid that it is rather deficient to all competitors out there (Scala, C#...). Aside from capturing mutable locals, one other major issue that goes unresolved is that they had discarded first-class function types, so you have to make do with SAM ("single abstract method")

For starters, to provide some context, here is the current text of Project Lambda proposal - it's a fairly short and readable document explaining both syntax and semantics. Here is the mailing list.

Project Lambda. The proposed syntax needs to be more Java-like.

There's a load of issues with semantics as well. They carried over a bunch of limitations from anonymous inner classes, such as inability to capture mutable locals (though at least you don't have to slap "final" on everything now, that will be inferred) - so it's still not true closures.

I was also rather disappointed by the way community input was handled in Project Lambda. Originally, it was unclear why they started it from scratch when there were as many as 3 major proposals for lambdas already (BCGA, CICE, FCM) which could be used as a base. The original claim was that community is too divided on those, and so a "clean slate" effort, guided by feedback of all interested parties, would reach a more universally accepted solution. What happened instead is that, after a lot of discussion on syntax and semantics, Sun - er, Oracle - just published their own spec and started to implement it right away. Pretty much all feedback on that was either quietly ignored, or disregarded under various reasons. This concerns both syntax and semantics.

With syntax it was especially disconcerting. Originally, there was a lot of discussion focusing on syntax on the mailing list, so Sun/Oracle folks declared a moratorium on it, saying that it's "not so important" and that "we can discuss it later", after semantics are figured out. Since then, their proposals have had a major unilateral revision of syntax, and that is seemingly final for the proposal given that it's what they plan to submit for JCP. So the syntax was effectively not discussed at all in any way that made a difference, even officially.

The only case of feedback on semantics seemingly making any difference was with respect to lexical scoping of identifiers in the lambda. Consider this code:

abstract class SamType {
int foo;
abstract int bar(int x);
}

class Test {
int foo = 123;
void baz() {
SamType f = #{ int x -> x + this.foo };
}
}

The question at hand was about what "this.foo" in the lambda body is supposed to mean. The original Sun/Oracle proposal wanted to have the same rules as for anonymous inner classes; in this case, since the lambda is an instance of SamType, this would mean resolving "foo" to SamType#foo on the lambda itself, and you had to write "this.Test.foo" to get the other one - again, same as with AICs. After a lot of negativity on the mailing list, they've changed it to use strictly lexical scoping - so "this.foo" now refers to Test#foo.

However, even in that case the attitude was interesting - when discussion started on the mailing list, Sun employees were quite dismissive of any criticism, and their response pretty much boiled down to "we believe users who're used to AICs will want lambdas to behave the same". Then suddenly they release a new spec with updated semantics, and no comments as to why they changed it, disregarding their own past arguments in favor of the old one.

So, as far as "community participation" goes, I'd say that Project Lambda has largely been a failure so far. We'll see if it favors any better in JCP.

As to its technical merits - we'll see when it gets released, but if this happens in its present shape, then I'm afraid that it is rather deficient to all competitors out there (Scala, C#...). Aside from capturing mutable locals, one other major issue that goes unresolved is that they had discarded first-class function types, so you have to make do with SAM ("single abstract method")

If you wanted to make this headline more sensational, you could change it to "Apache says GPLv2 license not good enough." which is what OpenJDK7 is licensed under.

Yeah, Apache may be at war with Oracle now, but this has the potential for much more widespread damage. It also puts the Free Software Foundation in an... interesting position, as this technically is the first salvo from Apache in a license war between GPL and Apache License.

Properties have been requested for ages, closures have been discussed for how long.

AFAIK properties are not on the radar, but lambdas are coming in Java 8. You can track the work (both design and implementation - there's already code to try out) here.

To me the Dalvik VM from a modern standpoint makes more sense on bytecode level than the registere based JVM.

It's Dalvik which is register-based (which makes fast interpreters easier to implement). JVM is stack-based.

That's the proprietary JDK. You're looking for OpenJDK, which is under the GPLv2.

An AC below pointed me to an article at zdnet that has a copy of the complaint and excerpts of the exhibits.

The one example listed is in PolicyNodeImpl: OpenJDK version, Android version.
It was released under the GPL as part of the OpenJDK, but the license has been changed to Apache 2.0 in the Android version. Unless the original author authorized this, that is not kosher. I can't find in in the HEAD of the Harmony repository. Also note that it appears in a test directory of the Android tree - probably included to test against their own implementation.

I personally look forward to helping bring Cocoa to OpenJDK and hope I'm not alone.

The BSD-port of OpenJDK already run on OS X. I don't know if they support using Cocoa yet but their mailing list would probably be a nice place to start looking for others that are interested in working on Cocoa support in OpenJDK.

Of course, what no one mentions is that Google has been one of the largest contributors to OpenJDK. About ten of the people on the list of OpenJDK committers are Google employees, and Google has had a couple of hundred patches submitted to the main repository.

Of course, they never had a big press release...

What about tablelayout https://tablelayout.dev.java.net/ It's available since 2002 but of course Sun didn't include it in the JDK. But you right anyway, GridBagLayout is the worst nightmare in Swing.

And if you're doing system programming, you wouldn't want to use a managed runtime then.

There are many system programming languages out there that have "managed runtimes" (even GC etc). This was the case even before C, much less after (think Oberon-3, D, Go...).

And Java language and VM were designed to remove the need for those pointers.

No, it was designed to "remove pointers", not to "remove the need for pointers", and that is for the sake of simplicity, not power. In other words, Java is explicitly designed to cover a certain subset of programming tasks well, and you're fine unless you venture beyond that.

NET has that feature, but when comparing managed vs managed runtimes having unsafe(unmanaged) pointers is a disadvantage.

C# has pointers so that you may conveniently do more things than you could do otherwise (e.g. in Java). I don't see how it is in any way a disadvantage. You're not required to use pointers. If you do use them, your code is non-verifiable and won't run in any security sandbox, so security is in no way compromised.

You cannot use pointers accidentally, either (you need to use the "/unsafe" compiler switch, and the "unsafe" keyword in the context in which they're used). And, in practice, pointers are not abused, either - I've only ever saw them used in C# in API interop circumstances, and even then only sparingly.

To sum it up, any code that is written in Java (without unmanaged pointers) is also written in C# in largely the same way (without unmanaged pointers), so Java does not have any advantage here. However, for cases where pointers are indispensable, or where their lack is very tedious to work around, C# is clearly superior.

That's as far as language goes. As for .NET itself - the reason why it has pointers (and many other things) in its type system is so that you can actually write an ISO C/C++ compiler that targets pure CIL. Try that with JVM.

Java and JVM have not been reviewed for a few years now. There are mostly debates what should be changed.

Are you on the lambda-dev mailing list? 'cause it's already way past debates on "should we change this", they're actively checking in code for lambdas for Java 7.

While I agree 100% that .NET has more features, I will have to take a neutral position on witch one is more advanced. Java VM is older and has quite a few tricks up it's sleeve(including overall VM performance), .NET's VM is younger and more dynamic

Have a look up the thread. I didn't start it - I replied to a post which was specifically comparing JVM and .NET on features, and was at times misleading, and at times blatantly false. My reply was solely to straighten that out.

I would agree with the general assessment that .NET is more full-featured while JVM (Sun's) has more advanced optimization techniques. It is important to understand, however, that some of those optimizations are important to JVM precisely because they are not reflected in the higher-level language/VM mechanics, such as type system. A good example being escape analysis & stack allocation for classes in JVM vs user-defined value types in CLR. Java GC is better optimized for the same reason - due to the lack of value types (and because stack allocation doesn't always happen), there are more heap allocations in a typical Java app compared to .NET. This is actually somewhat by design - .NET and C# were deliberately designed so that implementation can be simpler and needs to guess less (another example of that would be explicit "virtual" on methods).

It may still be that JVM is still faster in general (and it wouldn't really surprise me), but I didn't see any figures that conclusively settle

Thank you for this, PInvoke is probably my biggest reason in prefering .Net (mainly C#) over Java.

You can do this in Java with Java Native Access (JNA). From the JNA site:

JNA provides Java programs easy access to native shared libraries (DLLs on Windows) without writing anything but Java code—no JNI or native code is required. This functionality is comparable to Windows' Platform/Invoke and Python's ctypes. Access is dynamic at runtime without code generation.

Just for the record: What Sun said (now Oracle still says) about reading Oracle Java source code and creating a clean room implementation: JAVA RESEARCH LICENSE FAQ Question 18

18. Does the JRL prevent me from being able to create an independent open source implementation of the licensed technology?

The JRL is not a tainting license and includes an express "residual knowledge" clause which says you're not contaminated by things you happen to remember after examining the licensed technology. The JRL allows you to use the source code for the purpose of JRL-related activities but does not prohibit you from working on an independent implementation of the technology afterwards. Obviously, if your intention is to create an "independent" implementation of the technology then it is inappropriate to actively study JRL source while working on such an implementation. It is appropriate, however, to allow some decent interval of time (e.g. two weeks) to elapse between working on a project that involves looking at some JRL source code and working on a project that involves creating an independent implementation of the same technology

That will stop any copyright infringement claims against a reverse-engineered clean-room implementation. Without that, Sun and now Oracle could claim such an implementation was actually a derived work.

It doesn't apply to patents. You can infringe a patent even if you could somehow prove that you had no knowledge whatsoever of the original implementation.

It remains to be seen whether or nor Google's Dalvik infringes the patents Oracle now owns.

I'm not sure why everyone is considering Google the good guy here - this is about who gets to charge for the $X consumers are willing to spend on a phone. It's just a pissing contest over money. There's no "good" or "evil" side here - they're just two huge corporations fighting over how to cut up the pie of the mobile market.

Just for the record: What Sun said (now Oracle still says) about reading Oracle Java source code and creating a clean room implementation: JAVA RESEARCH LICENSE FAQ Question 18

18. Does the JRL prevent me from being able to create an independent open source implementation of the licensed technology?

The JRL is not a tainting license and includes an express "residual knowledge" clause which says you're not contaminated by things you happen to remember after examining the licensed technology. The JRL allows you to use the source code for the purpose of JRL-related activities but does not prohibit you from working on an independent implementation of the technology afterwards. Obviously, if your intention is to create an "independent" implementation of the technology then it is inappropriate to actively study JRL source while working on such an implementation. It is appropriate, however, to allow some decent interval of time (e.g. two weeks) to elapse between working on a project that involves looking at some JRL source code and working on a project that involves creating an independent implementation of the same technology

I'm sure you're right but I'll believe it when I see it. Years ago we were promised an open source Java (OpenJDK) but to this day it still depends on binary plugs. The only open source Java we have is Redhat's IcedTea but it was always meant to be a stop-gap solution until OpenJDK was fully opened. I thought OpenSolaris already open up until now, mostly because I never got around to have a good look at it, but it doesn't surprise me one bit that it depends on binary blobs given Sun's past with OpenJDK. Is it really that surprising that OpenSolaris never managed to build a strong community? I mean, if it were never fully open the I'd imagine many open source developers feel the same way I do - that it's a black box and waste of time.

Be warned - don't make promises you can't keep, because once you loose the trust of the community it's very, very hard to earn it back.

Would not make sense from a performance point of view, jacelle is possible but it has been dropped in later designs because it was slower than JIT solutions

If you read why that is it's not clear that it would apply to x86

http://weblogs.java.net/blog/2007/02/13/when-software-faster-hardware

He mentions that a JIT has an advantage over Jazelle (equivalent to his JPU case)

To be fair to the JPU, to get around the stack architecture problem, a JPU would probably implement a stack caching scheme where some registers will mirror some top N values on the Java operand stack. It will also have some registers mirror some locals. This effectively allows the JPU to avoid memory accesses just like the ideal JIT case, thereby allowing it to theoretically attain speeds approaching the ideal JIT case. However, register pressure also limits the JPU just as it limits the JIT.

In addition, the JPU can only mirror the top most operands on the stack, and maybe the first few locals. Which stack operand and/or locals get mirrored in registers usually isn't configurable at runtime. The JIT however can deal with this dynamically, and can arbitrarily choose which arguments and/or locals to keep in registers. Hence, the JIT has a higher probability of reducing memory accesses than the JPU.

Complex Bytecodes

But wait, that isn't the whole story. I said earlier that the above simple example was chosen because it shows off the JPU's best performance. Note that even when the JPU is best at its game, the JIT will still tend to beat its performance. Now consider the complex bytecodes in the VM instruction set (click here for a glossary of the VM bytecodes).

The VM instruction set also consists of bytecodes like new (for allocating objects), newarray (for allocating arrays), monitorenter (for locking an object), monitorexit (for unlocking an object), and field accessors like getfield, getstatic, putfield, putstatic, and many other complex bytecodes.

I call these bytecodes "complex" because their execution cannot be done in hardware. For example, new needs to work correctly in harmony with the VM's garbage collector; monitorenter needs to work in harmony with the VM's synchronization and threading mechanisms, etc. In the case of the field accessors, there bytecodes have to interface with the class' constant pool table which can be implemented differently depending on the software VM implementation. The constant pool entries will also need to be resolved (amongst other things) before the fields can be accessed.

Now it seems like an ARM has enough registers to mirror the x86 ones, so no extra loads. And x86 code doesn't have things like new which can't be implemented in hardware because it's an assembly language that is designed to run on hardware, not a byte code that is designed to run in a VM.

Most modern x86s actually map x86 instructions into Risc like uops before executing them, so it does seem like this technique is viable. Of course you need a lot of logic to do this. It's not clear what would happen performance-wise if you built an x86 instruction decoder as a front end for an ARM pipeline. There are probably legal issues too - there are still patents on x86. On the other hand, the patents on the core architecture will run out sooner or later.

Actually I don't think Microsoft will do this - A JIT or JPU for executing x86 code on ARM doesn't really appeal at all unless you have ARM cores that are faster than the fastest x86 to run it on. Right now the fastest shipping ARM cores probably have less performance than the slowest x86 - the Intel Atom. The fundamental problem is that ARM has aimed at the mobile market where power consumption is important. x86 has aimed at servers and desktops where power consumption is much less important than computational ability. Of course ARM has improved in performance and x86 has got thriftier but I be

Is Java doomed to get stuck behind in the single processor world or will it actually pave the way forward by running its VM across multiple cores?

The VM itselfs runs "across multiple cores" just fine - ultimately it JIT-compiles to native code for most performance-critical stuff, and that, obviously, will happily run on any core. The trick is writing Java code that is parallelizable.

This, of course, isn't a Java-specific problem - you're dealing with the same in any conventional language, be it Java, C++ or Python. The current pragmatic approach to this seems to be providing high-level libraries operating with primitives such as "tasks" and their dependencies, which are then scheduled across multiple cores automatically. Two notable examples are Apple's GCD, and Microsoft's Parallel FX (PPL for native, and Parallel LINQ for managed).

Now, not only is there a plan to add something similar to Java, but there is ongoing work on getting first-class functions (closures) into the language for the next major release, which is largely motivated by the requirements of such libraries (similar to how Apple added __block for GCD - those libraries become too unwieldy to use without this kind of thing).

As a whole the generics is a useless and dangerous disaster

You keep repeating that. Citation needed.

Since this is the first time I have ever commented on this topic it seems unlikely that I "keep repeating it". And I gave two examples in my comment. But also see Ken Arnold's opinion: http://weblogs.java.net/blog/arnold/archive/2005/06/generics_consid_1.html and http://www.artima.com/weblogs/viewpost.jsp?thread=222021 and Joshua Bloch's attempts at favorable treatment are pretty damning: http://java.sun.com/developer/technicalArticles/Interviews/bloch_effective_08_qa.html.

Java generics seems to require at least a graduate level course in type theory to use (possibly an actual degree in the field)

So? Is this a bad thing? It's like saying "expert field" seems to require at least "expert field" graduate level course. If you are no expert, then don't use java generics. And if you can't read other's code, then maybe we should hire someone who can.

Indeed it is a bad thing. A problem that all excessively obscure and complex languages have rapidly revealed (C++, Perl) is that every difficult-to-use feature gets used (if it is usable at all) and has to be supported by every other programmer eventually since 90% of all programming is support of existing code.

The saving grace for Java generics is that beyond container typing it seems sufficiently hard to use that it rarely gets used. Some time back I scanned the source of several substantial and active open source projects without finding any examples in use beyond container typing.

I remember using java generics to build a visual keyboard for any kind of text component. I'm reading my code now, and yes, I understand it.

Beyond container typing what aspects did you actually use? Have you ever written one genuine generic algorithm? That is - an algorithm with a generic interface that takes any appropriate generic type and returns an appropriate result type while maintaining typing throughout?