Apache resigns from the Java Community Process executive committee [LWN.net]

Apache resigns from the Java Community Process executive committee

Posted Dec 10, 2010 2:39 UTC (Fri) by mikov (guest, #33179)
Parent article: Apache resigns from the Java Community Process executive committee

This is really really sad, although clearly not unexpected. Unless Oracle makes dramatic license changes in the near future, I don't think Java can be viewed as a "free language". It is absurd that there can be only one GPL implementation of Java.

Somewhat offtopic: Mono, as a Java alternative, doesn't really seem well suited for Linux development because of this:
http://www.mono-project.com/Mono:Runtime#IO_and_threading

to post comments

Apache resigns from the Java Community Process executive committee

Posted Dec 10, 2010 3:32 UTC (Fri) by bojan (subscriber, #14302) [Link] (32 responses)

> It is absurd that there can be only one GPL implementation of Java.

ASF doesn't release under the GPL. This was about releasing Harmony (modular Java runtime with class libraries and associated tools) under AL, 2.0.

Apache resigns from the Java Community Process executive committee

Posted Dec 10, 2010 5:07 UTC (Fri) by mikov (guest, #33179) [Link] (28 responses)

I think most of us are aware that the Apache Foundation uses the Apache License :-)

My point was that even though the GPL goes to great lengths to ensure freedoms (much more so than the AL), and the "blessed" Java implementation is GPL, it is nevertheless impossible to develop another free implementation. It defies belief. But all this been said before...

In fact I did myself suspect a weakness in the GPL and warned against it back in 2006, though it came about in a different way:
http://slashdot.org/journal/153146/GPL-can-be-retroactive...
(I think I may have already posted this URL in a previous discussion, for which I apologize - I am not trying to pimp my Slashdot account)

Ironically Oracle bought both MySQL and Sun...

Apache resigns from the Java Community Process executive committee

Posted Dec 10, 2010 6:05 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (27 responses)

"it is nevertheless impossible to develop another free implementation."

This is not true. It is certainly possible and Google has done so. Whether you will be getting sued for alleged patent violation however is a entirely different matter and GPL or for that matter any copyright license wouldn't be able to prevent this from happening for independent implementations. What you really ought to be complaining about is Sun or Oracle not released TCK under a license that allows independent implementations to certify themselves as Java easily and therefore get the benefits of the Sun patent grant for compliant implementations. You can also very well complain about the copyright license agreement that centralizes copyright control as has happened with many Sun/Oracle projects.

No major party seems to believe that GPL can be retroactively revoked. I don't think that idea has any merit whatsoever.

Apache resigns from the Java Community Process executive committee

Posted Dec 10, 2010 6:34 UTC (Fri) by bojan (subscriber, #14302) [Link] (2 responses)

> It is certainly possible and Google has done so.

Are you talking about Dalvik here? That's based on Harmony. No?

Apache resigns from the Java Community Process executive committee

Posted Dec 10, 2010 6:51 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

Yes and with additional modifications from Google and it *is* Free software under the Apache license. Just because Oracle filed a lawsuit against Google doesn't make it automatically non-free.

Apache resigns from the Java Community Process executive committee

Posted Dec 10, 2010 20:56 UTC (Fri) by bojan (subscriber, #14302) [Link]

But that will never be Java, because Oracle won't let it become Java. That's what all this is about.

Apache resigns from the Java Community Process executive committee

Posted Dec 10, 2010 13:22 UTC (Fri) by mikov (guest, #33179) [Link] (22 responses)

Sigh. The TCK is one of the main reasons why Apache its resigning, and clearly that *is* what I am complaining about. That is the whole point. Despite of being licensed under GPL by its owner, Java cannot be considered free, because that same owner will prosecute you if you tried to implement it independently.

About the ability to revoke GPL retroactively. Unfortunately your optimistic unsupported assertion that such fear has no merit is not enough on its own. Just because we want something doesn't make it true. I have linked to pretty solid legal arguments that would have to be refuted by reasonable counter-arguments.

I have even seen Eben Moglen implicitly confirming this, though I think that link is dead now unfortunately.

Apache resigns from the Java Community Process executive committee

Posted Dec 10, 2010 14:42 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (21 responses)

Your argument seems confused to me. TCK doesn't decide whether a implementation is free or not. Apache is free to continue developing harmony and it will remain under a free software license. Apache's issue must be that they cannot call their implementation Java and whether one can call something by some particular name has nothing whatsoever to do with whether or not a GPL'ed implementation exists. I don't see the connection. A GPL'ed implementation can only guarantee certain rights in terms of copyright licensing and to some extend patent rights assuming you use the same exact implementation. You can still be sued for a independent reimplementation. You can still be sued for trademark violation and so on.

As to the question of whether GPL can be revoked, it is sufficiently answered by looking at how many vendors are exercises GPL rights and have huge legal departments. If they have convinced themselves that it is not a risk worth worrying about, I don't see why I should be concerned about supposedly implicit admission on a link you cannot find. It seems too flimsy. I will let an actual court case decide on it. Until, the burden of proof exists on the side making that claim.

Apache resigns from the Java Community Process executive committee

Posted Dec 10, 2010 15:31 UTC (Fri) by DOT (subscriber, #58786) [Link] (7 responses)

You're right that a trademarks can do limited damage to a free software project. If project management gets really bad, the project can be forked with a new name.

But Oracle also claims to hold patents for Java, which OpenJDK gets away with because of a special TCK license that only applies to OpenJDK. Harmony isn't so lucky, so if Oracle is evil, they can sue the pants off distributors like Google. So that's why Apache would really want to get a license for the TCK and the patent license that comes with it.

Since that's impossible unless you're substantially the same as Oracle's version of OpenJDK, Java is not free, and OpenJDK is not free either. Software that can't be forked is not free. A language that can't be legally implemented is not free.

Apache resigns from the Java Community Process executive committee

Posted Dec 10, 2010 16:02 UTC (Fri) by paulj (subscriber, #341) [Link] (1 responses)

OpenJDK gets an Oracle patent licence because of its GPL licensing - nothing to do with TCK.

Other implementations, i.e. those independent of OpenJDK, *may* get a patent licence from Oracle if they show they conform, which requires the TCK.

Apache resigns from the Java Community Process executive committee

Posted Dec 13, 2010 4:38 UTC (Mon) by aliguori (guest, #30636) [Link]

It's a bit more subtle than that. Just about any software that you distribute would carry an implicit patent license (at least in the US) for patents you owned. The GPL goes a step further and says that the patent license must be non-discriminatory to future downstreams which basically is anything that can claim to be a derivative product.

So in theory, even if I just copied a few lines of code from OpenJDK and implemented everything else from scratch, I still get full patent licenses. The catch is, if I copy anything from a GPL software, my license must be GPL-compatible and the end-result is something that is effectively GPL'd.

By the virtue of being Apache Licensed, there is no way Harmony can claim to be a derivative product of OpenJDK which means it doesn't get to share the patent license. If they integrated two lines of OpenJDK code and relicensed to GPL, they'd be covered.

Apache resigns from the Java Community Process executive committee

Posted Dec 10, 2010 16:28 UTC (Fri) by paulj (subscriber, #341) [Link] (3 responses)

Your argument that free software must be independently re-implementable, under other, less restrictive licences, doesn't seem like something that'd be universally agreed on. That would imply that when patent grants were added to GPLv3 which extend ONLY to downstream recipients of the software (i.e. NOT to the implementation generally) that they created a non-free licence, or at least less-than-free.

I'd agree that the Java language specification is less than free. It's clearly patent encumbered. However, I find it hard to agree with how you then try to paint OpenJDK as being non-free.

Apache resigns from the Java Community Process executive committee

Posted Dec 10, 2010 17:24 UTC (Fri) by DOT (subscriber, #58786) [Link] (2 responses)

It sure isn't universally agreed on. Many people don't want free software licenses to say anything about patents. And before today, I also thought of the GPL as an utterly free software license, but this "downstream recipients only" concept does not sound free to me at all. If restricted at all, the patent license should be restricted to all GPL licensed software, not just the one project, which would bring it in line with the strong copyleft mechanism that the rest of the GPL employs.

Apache resigns from the Java Community Process executive committee

Posted Dec 13, 2010 3:22 UTC (Mon) by jamesh (guest, #1159) [Link]

I agree that a plain patent license would be better than having the patent licensing bundled with a particular implementation, but if you're producing another implementation with the same license, why not just copy and adapt the code for the covered technique?

If you're developing an implementation with a less restrictive license, it is quite possible that the patent holder has no intention of freely licensing the patent under those terms.

Apache resigns from the Java Community Process executive committee

Posted Dec 13, 2010 15:53 UTC (Mon) by pboddie (guest, #50784) [Link]

And before today, I also thought of the GPL as an utterly free software license, but this "downstream recipients only" concept does not sound free to me at all.

But how else would a licence based on the principles of copyright actually function?

Apache resigns from the Java Community Process executive committee

Posted Dec 10, 2010 18:48 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]

If you believe, patent encumbered software is non-free then you would call ffmpeg non-free as well even though it under a GPL license but that is a incomplete and rather misleading perspective since organizations like FSF would point out that patents are not universal and when we have talk about free software licenses, we are usually referring to the copyright licensing and not patent status since in many cases, this is unknown. I think it makes sense to clearly separate encumbrances in copyright, patents and trademarks and not lump them together since they all have very different implications.

To summarize, OpenJDK is free software. Harmony is also free software. The former has a patent grant (being TCK compliant) as well as a patent license due to the GPL license. Harmony has neither. That doesn't make it non-free and a GPL'ed implementation can't protect you. It won't get the patent grant since Apache disagrees with the TCK terms and won't be able to carry the Java trademark however.

Apache resigns from the Java Community Process executive committee

Posted Dec 10, 2010 20:58 UTC (Fri) by bojan (subscriber, #14302) [Link] (5 responses)

> TCK doesn't decide whether a implementation is free or not.

TCK decides whether it's Java. If you don't pass TCK, you don't have Java.

Apache resigns from the Java Community Process executive committee

Posted Dec 11, 2010 2:18 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link] (4 responses)

Sure and the GPL'ed isn't called Java. It is called OpenJDK. So I am puzzled why mikov seems surprised that Oracle is enforcing their trademarks and patents. GPL cannot possibly protect from Oracle suing over independent reimplementations.

Apache resigns from the Java Community Process executive committee

Posted Dec 13, 2010 2:43 UTC (Mon) by jmalcolm (subscriber, #8876) [Link] (3 responses)

This is not about trademarks, it is about patents. Any non-TCK validated implementation (including versions of OpenJDK that extend or omit elements of the spec) do not receive a patent license from Oracle. This is their position.

So, even OpenJDK is not "free software" in any way that I have come to understand it. I am not free to modify it.

Apache resigns from the Java Community Process executive committee

Posted Dec 13, 2010 6:22 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

I don't know if that's their position but I doubt it is since GPL license itself has a implicit patent license that is available regardless of whether it is TCK compliant or not. So if you use OpenJDK or a derived codebase then you get that. It is possible for you to modify software outside the boundaries of standard Java and get sued for unrelated patents but that can happen to any piece of software. Claiming that this makes it non-free is not logical since any software carries that risk.

Apache resigns from the Java Community Process executive committee

Posted Dec 13, 2010 8:57 UTC (Mon) by jmalcolm (subscriber, #8876) [Link] (1 responses)

I believe that you can "modify software outside the boundaries of standard Java" as you say and be sued for "related" patents.

The GPL gets it's power from copyright. This means the extent of the power of the GPL is to remove the right to distribute. That is it.

Who has the power to enforce the GPL in the case of OpenJDK? Only Oracle.

http://www.gnu.org/licenses/gpl-faq.html#WhoHasThePower

What does the GPL mean for Oracle if they sue a user of a GPL implementation of Java (even OpenJDK) for patent violation? Nothing.

Is Oracle going to restrict Oracle from distributing OpenJDK? No. So, what power does the GPL have over Oracle? None.

Now, OpenJDK "as released" has an explicit patent grant. However, modified versions of OpenJDK do not. In fact, if they "superset" the Java spec they explicitly do not have a grant.

Here is what an editorial on this very site had to say:

"Sun released much of the Java code under the GPL - eventually - but it never made Java truly free. The company went out of its way to retain control over the language and of any implementations of it; control over the specifications, copyright licensing policies forcing control over the code, and software patents held in reserve do not add up to a platform one can trust. Sun seemingly feared forks above all else, and so went out of its way to eliminate the freedom to fork whenever possible."

I agree with this excerpt. We do not have the freedom to fork OpenJDK.

I read a lot about the "implicit" patent grant in GPL2. I am not sure where this comes from but I imagine it is rooted in something like estoppel since it seems "reasonable" to assume you have the right to use software that was released under the GPL by the patent holder. I sometimes read that "Section 7" of the GPL gives the "implicit" patent license but my reading of that section just says that if Oracle sues you, you also lose the right to distribute Java.

You can read the text yourself here:

http://www.gnu.org/licenses/old-licenses/gpl-2.0.html

As above, Oracle can still happily distribute under the GPL after they sue someone. They are not getting their rights from the GPL. It has no power over them.

All that said, I do not see how this "implicit" grant would overrule the "explicit" non-grant from Oracle anyway. You would not know until you went into court though so I admit anything is possible.

Apache resigns from the Java Community Process executive committee

Posted Dec 13, 2010 9:53 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

On the question of who has the power, Oracle is not the only copyright holder. Red Hat has been a significant contributor to OpenJDK and IBM has signed a deal with Oracle to be a contributor as well. If I get a piece of code from any author under the GPL license, all the terms stand and while the copyright holder can license the code under other licenses if they want to (assuming they retain copyright to all of the codebase atleast in a shared manner), they cannot take away the rights granted to me under the GPL retroactively and this included any patents rights as applicable to the codebase. Whether derivatives can infringe on additional patents is a entirely different question but whatever patents are applicable to standard Java specs, I have a license to use them regardless of the TCK and if I use OpenJDK without modifications, the TCK patent grant is applicable as well. If you don't share this perspective, we have a disagreement on what the implications of the license is and we will have the let the court sort it out when it happens. I am going to continue to consider OpenJDK as fully free software under the GPL license.

Apache resigns from the Java Community Process executive committee

Posted Dec 11, 2010 4:26 UTC (Sat) by mikov (guest, #33179) [Link] (2 responses)

Releasing under a free license doesn't necessarily make software "free". Say, you disassemble MS Word and publish the resulting source under GPL. I don't think many people would argue that the result is "free" by any definition.

Similarly, Java cannot be considered "free" by me and many others if an independent implementation is under real patent threat from Oracle. In the USA I cannot safely use and distribute Harmony or Dalvik. So how can they be considered free? Free for what?

About retroactive GPL revocation. Not all projects are vulnerable. Projects with multiple contributors like Linux, or projects with copyright assignment to FSF, are safe. So it cannot be said that the GPL is especially vulnerable or bad. But there is risk and it would be naive to ignore it.

Of course it is up to you (or your business, your lawyer, etc) to make up your own mind whether GPL revocation is a risk. However deciding it is safe just because other people appear to think it is safe, without knowing their detailed reasoning, is probably not the best strategy.

Apache resigns from the Java Community Process executive committee

Posted Dec 11, 2010 7:16 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]

Again, we aren't comparing the same things. I don't think disassembling and patent infringement is comparable at all. If Oracle wins a patent lawsuit against Google directly on Harmony code and there isn't any workaround, then it becomes a problem. Until then, it is just a patent lawsuit and we have many of them floating around. At the present situation, Harmony is free software by any reasonable logic.

Yes, the details of GPL licensing can affect different parties in different ways but if so many different vendors and consumers haven't raised such a problem, I don't see why I need to worry about it. It is just hot air. If we are going to listen to random lawyers, there was one claiming that BSD is incompatible with GPL license and many many more weird postulations. If you can find some prominent vendor's legal department or folks like Eben Moglen say it, then I will start paying more attention.

Apache resigns from the Java Community Process executive committee

Posted Dec 13, 2010 16:07 UTC (Mon) by pboddie (guest, #50784) [Link]

Releasing under a free license doesn't necessarily make software "free". Say, you disassemble MS Word and publish the resulting source under GPL. I don't think many people would argue that the result is "free" by any definition.

Suddenly we have two people trying to prove a point by referring to situations involving the "re-release" of proprietary software. If you don't have permission to redistribute a work, you certainly aren't allowed to put a licence of your choice on it and redistribute it at all, whether you want to apply the GPL or something else to it. So that really has nothing to do with software legitimately distributed under the GPL.

Apache resigns from the Java Community Process executive committee

Posted Dec 13, 2010 2:39 UTC (Mon) by jmalcolm (subscriber, #8876) [Link] (3 responses)

If an implementation does not pass the TCK then it explicitly does not have a patent grant from Oracle. They are very clear about this.

To my mind, this means that any implementation that has not passed the TCK is not "free" in the libre sense. This includes any modified version of the GPL version released by Oracle. It is really not available at zero cost either as you would have to license the patents for money.

Just because Oracle has not gotten around to suing you does not make it free.

What definition are you using? Can I download a pirated version of Windows and call that "free"? I mean, just because I explicitly do not have the legal right to use it means nothing as long as I can get a hold of it right? That seems to be what you are saying.

What is the difference between a GPL version that I cannot legalll modify and a commercially licensed version?

Apache resigns from the Java Community Process executive committee

Posted Dec 13, 2010 3:57 UTC (Mon) by jamesh (guest, #1159) [Link] (2 responses)

If you modify OpenJDK such that it no longer conforms to the TCK and release the result under the GPLv2, what exactly is Oracle going to sue you for?

The GPL alone has given you permission to redistribute, modify, and distribute modified versions of the software.

Apache resigns from the Java Community Process executive committee

Posted Dec 13, 2010 9:22 UTC (Mon) by jmalcolm (subscriber, #8876) [Link] (1 responses)

IANAL, but they "could" sue you for violating their patents.

Some people believe that the GPL version 2 gives an "implicit" patent grant. Section 7 of the GPL does seem to imply that, if I modify GPL software and redistribute it, I must be implicitly granting patent rights to my changes. Otherwise I would not have the right to redistribute the original GPL code (which I did).

However, if I am the original author of the software that I release under the GPL version 2, then Section 7 (or indeed any other part of the GPL) does not obligate me to do anything.

It is likely that you would be able to argue in court that it was "reasonable" to assume that you could use the GPL software without violating the authors patents if the original author did not mention patents when they released the code. Again, an "implicit" patent grant.

In the case of Java however, Oracle has "explicitly" stated that you "do not" have patent protection unless you exactly implement the Java spec.

Apache resigns from the Java Community Process executive committee

Posted Dec 14, 2010 1:10 UTC (Tue) by jamesh (guest, #1159) [Link]

I don't quite follow your argument. I don't dispute that Oracle is not bound by the GPL: as copyright holders they are free to distribute copies of the software under whatever license they want.

But the copy I received from Oracle was licensed under the GPL, and that says I can modify, redistribute and distribute modified versions. If the code they gave me exercises their patents, then a court is going to rule that Oracle licensed my use of those patents to the extent necessary to exercise my rights under the GPL. That is the implicit patent grant people are talking about.

Note also that if Oracle were to assert that they hadn't given you the patent rights necessary to modify, redistribute and distribute modified versions of OpenJDK, then no one would be able to redistribute the copies of OpenJDK that they received from Oracle (e.g. your favourite Linux distro). Because if they can't pass on those rights, they have no right to distribute the code.

So can you point out where Oracle has explicitly stated that OpenJDK users do not have the patent rights required to exercise their rights under the GPL?

Apache resigns from the Java Community Process executive committee

Posted Dec 13, 2010 2:33 UTC (Mon) by jmalcolm (subscriber, #8876) [Link]

"it is nevertheless impossible to develop another free implementation."

This is completely true.

You cannot develop a free version of Java that does not violate Java patents (according to Oracle). How "free" is an implementation that is explicitly patent encumbered?

Apache resigns from the Java Community Process executive committee

Posted Dec 13, 2010 2:30 UTC (Mon) by jmalcolm (subscriber, #8876) [Link] (2 responses)

Ok, so the comment should have been "there can only be one GPL version of Java and absolutely no implementations using other free licenses (like APL)".

According to Oracle's rules, you cannot implement Java without passing the TCK and they will not license you the use of it for a free implementation.

Also, you cannot extend the GPL version they release. If, for example, I modified Oracle's GPL version to support proper Tail-Call Optimization (for use with Clojure perhaps) I would have violated the license terms of the Java patent grant (I extended the spec) and my version would be infringing.

Also, how "free" is a GPL version that I cannot modify as I see fit?

Apache resigns from the Java Community Process executive committee

Posted Dec 13, 2010 6:24 UTC (Mon) by paulj (subscriber, #341) [Link] (1 responses)

That's not true. You have *two* patent grants with the GPL version: via the Java spec conformance & via the GPL. If you modify the JVM in OpenJDK you may lose the spec grant, however you will still have the GPL grant.

Apache resigns from the Java Community Process executive committee

Posted Dec 13, 2010 18:27 UTC (Mon) by rahvin (guest, #16953) [Link]

The people before you are arguing that GPL "explicit grant" had never been tested in court, AND that it wouldn't apply to Oracle. They are both suppositions but still valid concerns. Unfortunately this won't be tested in the Oracle/Google case. In fact it's going to be very hard to test this, patent suits are extremely expensive and convoluted and unless someone with really deep pockets (ala Google) steps forward and challenges the GPL explicit patent grant then Oracle still has the threat of a patent lawsuit against any implementation.

IMO until Oracle provides a truly free patent grant the community should abandon Java. If enough of the community publicly abandons Java like Apache has done then maybe Oracles will see the damage it will cause.

Personally I applaud the Apache Foundation.

Apache resigns from the Java Community Process executive committee

Posted Dec 10, 2010 6:01 UTC (Fri) by eru (subscriber, #2753) [Link] (9 responses)

absurd that there can be only one GPL implementation of Java.

Since the limitations are based on trademarks, couldn't you work around the problem by not calling your alternate implementation Java? It could otherwise implement precisely the same language.

I realize the way Java works can cause problems: paths to standard classes contain the word "java" and other trademarks. The question of whether the alternate implementation can use path names likes this could keep a troop of lawyers employed for years...

Apache resigns from the Java Community Process executive committee

Posted Dec 10, 2010 6:19 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

It is usually the public facing end user stuff that trademark covers. For example, CentOS has many packages and files with the name "redhat" in it including the old redhat-config* and /etc/redhat-release and noone bothers about that. Websites, about boxes in prominent programs etc may however be problematic. IANAL of course.

Apache resigns from the Java Community Process executive committee

Posted Dec 10, 2010 7:16 UTC (Fri) by tzafrir (subscriber, #11501) [Link] (1 responses)

Centos does have /etc/redhat-release . That file, though, states that the system is a Centos system.

Apache resigns from the Java Community Process executive committee

Posted Dec 10, 2010 7:38 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]

Yep precisely my point. The filename itself is not a problem. The content is replaced because it is used in used in *other* user visible places.

Apache resigns from the Java Community Process executive committee

Posted Dec 10, 2010 6:32 UTC (Fri) by bojan (subscriber, #14302) [Link] (2 responses)

> It could otherwise implement precisely the same language.

That exactly is the problem. It can work in exactly the same way, but because it didn't pass TCK (which you cannot get, obviously), then it will never be Java. So, when you try to convince you "customers" that it is, you lose.

Apache resigns from the Java Community Process executive committee

Posted Dec 10, 2010 13:03 UTC (Fri) by mikov (guest, #33179) [Link] (1 responses)

If it doesn't pass the TCK, which it can't since the field of use restrictions are incompatible with free licenses, it doesn't get a patent grant from Oracle. Oracle has shown that it is willing to enforce these patents. So you and your customers would be crazy to voluntarily assume such a vulnerable position.

Apache resigns from the Java Community Process executive committee

Posted Dec 10, 2010 21:01 UTC (Fri) by bojan (subscriber, #14302) [Link]

Precisely. And even before they sue you over patents, you also cannot legally call it Java, so that's a double whammy.

Apache resigns from the Java Community Process executive committee

Posted Dec 10, 2010 11:43 UTC (Fri) by Wol (subscriber, #4433) [Link] (2 responses)

"Since the limitations are based on trademarks, couldn't you work around the problem by not calling your alternate implementation Java?"

One would have thought so. But isn't that EXACTLY why Oracle is suing Google?

The whole point of Dalvik is "Dalvik is not Java", and they still get sued ...

Cheers,
Wol

Apache resigns from the Java Community Process executive committee

Posted Dec 10, 2010 12:16 UTC (Fri) by sorpigal (subscriber, #36106) [Link] (1 responses)

That's because it *isn't* just trademarks, it's patents too. At least that's what Oracle alleges. To be fair they also allege copyright infringement, so clearly crazy things are being asserted.

Apache resigns from the Java Community Process executive committee

Posted Dec 10, 2010 18:53 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]

I don't think it is that crazy. It appears Google did use a disassembler although Google disagrees, naturally.

http://www.theregister.co.uk/2010/11/12/google_accuses_or...

Apache resigns from the Java Community Process executive committee

Posted Dec 11, 2010 0:37 UTC (Sat) by RogerOdle (subscriber, #60791) [Link] (40 responses)

Mono is not, by any stretch of the imagination, a suitable replacement for Java. All you would accomplish is changing your masters from Oracle to Microsoft. Mono is at least as encumbered by patents as Java is. Just say no to Mono.

(Isn't Mono the kissing disease? That should be warning enough. They lure you in with a pretty face before they hit you with the virus.)

If Apache leaves Java behind then it should find or sponsor a patent free alternative language. An interpreted version of C++ would probably be least painful. I am not a C++ fan but what is closer to Java? Java has a huge memory foot print, I would welcome a reimagined alternative that is leaner, meaner, and faster.

Apache resigns from the Java Community Process executive committee

Posted Dec 11, 2010 0:48 UTC (Sat) by JohnLenz (guest, #42089) [Link] (32 responses)

I don't know if it could replace Java but Vala is one option. It is mostly like what you describe, a hosted version of C with real classes, real interfaces, real namespaces, memory management, etc... but still can access normal C libraries.

Perhaps if a lot of groups like Apache got behind vala it could take off as a java replacement. See for example this page

Apache resigns from the Java Community Process executive committee

Posted Dec 11, 2010 22:48 UTC (Sat) by cmccabe (guest, #60281) [Link] (31 responses)

All of the stuff I've read about Vala seems to portray it mostly as a framework for developing GTK applications. I guess, having invested so much time in the GObject framework, they followed the natural path and made their framework into its own language. C++ evolved the same way; originally, it was just a preprocessor called CFront that generated C code.

All the extended C languages have similar problems-- they're trying to graft high-level features on a language that was never designed for them. If you're writing a GUI, why on earth should you do memory management manually, or worry about heap corruption?

So really, if you're going to use an extended-C language, you might as well pick C++. You'll have the most potential contributors. Now whether or not you *should* use an extended-C language is a separate debate, and it depends on your application...

Apache resigns from the Java Community Process executive committee

Posted Dec 12, 2010 0:25 UTC (Sun) by JohnLenz (guest, #42089) [Link] (28 responses)

All of the stuff I've read about Vala seems to portray it mostly as a framework for developing GTK applications.

Yeah, that is why I said that vala as it is now it can't replace Java. There is no reason in the language that it couldn't add support for other toolkits or for better support for server programming: something like tomcat for vala. This is just adding some of the available libraries. The reason to start from vala instead of something else is that the syntax and functionality of the language itself are very close to Java and C#.

Yeah, but vala is not an extended C language; the easiest way to see this is that vala has no pointers. Vala is like java or c# where everything is a pointer and you get nullreferenceexceptions. Plus vala has managed memory.

The reason not to use C++ is like you said: why would you want to go back to managing memory?

Apache resigns from the Java Community Process executive committee

Posted Dec 12, 2010 15:05 UTC (Sun) by HelloWorld (guest, #56129) [Link] (26 responses)

> The reason not to use C++ is like you said: why would you want to go back to managing memory?
95% of all memory management issues can be dealt with using reference counting, which C++ makes _very_ easy with classes such as shared_ptr.

Apache resigns from the Java Community Process executive committee

Posted Dec 13, 2010 4:03 UTC (Mon) by jamesh (guest, #1159) [Link]

Reference counting has its problems. If you have cycles in your data structures, you end up with leaks.

It also means that code paths that only read a data structure end up writing to it to update the reference count. This usually involves the CPU core acquiring exclusive access to the cache line containing the reference count, where it might otherwise have been able to run with shared access.

Apache resigns from the Java Community Process executive committee

Posted Dec 14, 2010 0:03 UTC (Tue) by cmccabe (guest, #60281) [Link] (24 responses)

Just for fun, can you spot the bug in this code?

> extern void fun1(std::tr1::shared_ptr<int> a, int b);
>
> extern short fun2();
>
> void fun3() {
> fun1(std::tr1::shared_ptr<int>(new int(2)), fun2());
> }

Apache resigns from the Java Community Process executive committee

Posted Dec 14, 2010 0:29 UTC (Tue) by HelloWorld (guest, #56129) [Link] (23 responses)

Yes, the problem with this approach is documented here:
http://www.boost.org/doc/libs/1_36_0/libs/smart_ptr/share...

I agree that this is a very nasty problem, and I'm not sure I would have spotted it in a code review.

What makes it worse is that there is no good way to avoid this problem. One could make all constructors private and create objects through static member functions which immediately wrap every new-ed pointer in a shared_ptr. But that requires boilerplate code, and a reusable solution can't be done well in C++98 (because of the perfect forwarding problem and because there are no variadic templates). It's really pretty bad, thanks for pointing that out.

Apache resigns from the Java Community Process executive committee

Posted Dec 14, 2010 5:05 UTC (Tue) by cmccabe (guest, #60281) [Link] (22 responses)

There is only one way to avoid the problem: experience. You must not allow people to use anonymous shared_ptr objects; it's too dangerous.

Here's another traditional memory leak, which I don't think you'll need teh Google to spot:

> #include <iostream>
> #include <tr1/memory>
>
> using std::tr1::shared_ptr;
> using std::cout;
>
> class Foo {
> public:
> Foo() {}
> };
>
> class Bar : public Foo {
> public:
> Bar(int b_) : b(b_) { }
> private:
> int b;
> };
>
> int main(void) {
> Foo *my_foo = new Bar(5);
> shared_ptr<Foo> my_shared_foo(my_foo);
>
> return 0;
> }

Apache resigns from the Java Community Process executive committee

Posted Dec 14, 2010 12:53 UTC (Tue) by HelloWorld (guest, #56129) [Link] (21 responses)

> There is only one way to avoid the problem: experience. You must not allow people to use anonymous shared_ptr objects; it's too dangerous.
It's hard to enforce this kind of rule though. These things are easy to overlook in a code review.

> Here's another traditional memory leak, which I don't think you'll need teh Google to spot:
I didn't use "teh google" for the other one, I just knew that pitfall already. I have no idea what might be wrong with the second one though.

Apache resigns from the Java Community Process executive committee

Posted Dec 14, 2010 18:07 UTC (Tue) by cmccabe (guest, #60281) [Link] (20 responses)

> I didn't use "teh google" for the other one, I just knew that pitfall
> already. I have no idea what might be wrong with the second one though.

The implicit non-virtual destructor causes slicing.

It's possible to write correct code in C++, but it requires a *lot* of self-discipline. You can make all the same mistakes a C programmer can, plus a whole lot more.

Apache resigns from the Java Community Process executive committee

Posted Dec 14, 2010 22:14 UTC (Tue) by foom (subscriber, #14868) [Link] (6 responses)

While of course you're exactly right that calling the destructor on Foo when the instance is of Bar is a bad mistake to make, your *particular* example, at least with gcc, will not cause a memory leak. That is simply because Bar's destructor doesn't do anything. The only action taken, in the end, is to call free(my_foo), which works perfectly well and still releases all the memory when my_foo is a "Bar" object rather than the Foo object it is declared to be.

Now, if, instead of "int b;", you'd put "std::string b;" as the member of Bar, then you'd have an actual leak. :)

Apache resigns from the Java Community Process executive committee

Posted Dec 15, 2010 0:51 UTC (Wed) by paulj (subscriber, #341) [Link] (5 responses)

Serious? The destructor that gets called is the base class, not that of instantiated type of the object, cause the shared_ptr uses the base class type? Is that a flaw in shared_ptr or in the underlying language? That's just amazing...

Apache resigns from the Java Community Process executive committee

Posted Dec 15, 2010 2:03 UTC (Wed) by nix (subscriber, #2304) [Link] (1 responses)

That's because the destructor isn't virtual. That's what the absence of virtual *means*. (Now perhaps the fact that virtual wasn't default, with lack-of-virtual an option, *is* a language flaw.)

Apache resigns from the Java Community Process executive committee

Posted Dec 15, 2010 7:08 UTC (Wed) by paulj (subscriber, #341) [Link]

Ah yes, of course. Keep forgetting about C++'s selective inheritance.

Apache resigns from the Java Community Process executive committee

Posted Dec 15, 2010 2:14 UTC (Wed) by foom (subscriber, #14868) [Link] (1 responses)

No no, you misunderstand. It's not as bad as that. What destructor shared_ptr calls depends on the declared type of the argument in its constructor, not the type of the shared_ptr itself. So, in an idiomatic spelling:
> shared_ptr<Foo> foo(new Bar(5));
everything works fine, because the argument is of type "Bar *" (that being the return type of the new expression).

It's only in the case of:
> Foo *foo_rawptr = new Bar(5);
> shared_ptr<Foo> foo(foo_rawptr);

that you get wrong behavior.

That is a feature of C++ the language: it lets you decide whether you want to keep track of the runtime type of the object or not. "Not" is a very important use-case: it allows you to use many of the features of C++ even in situations where adding a class-pointer word to every instance would be excessively expensive, or impossible (e.g. mmaping a file full of structs from disk).

So anyhow, the *default* is to not track the runtime-type. However, if you mark the destructor "virtual", then it *will* add a word to the size of the object instance to keep track of the actual type, and then delete will call the destructor for "Bar", even in the second case.

Taking shared_ptr out of the picture for simplification, the thing that doesn't work without a virtual destructor is:
> Bar *bar = new Bar(5);
> Foo *foo = bar;
> delete foo;

(that is: where the static type of the argument to delete is different from the dynamic type of the object).

Apache resigns from the Java Community Process executive committee

Posted Dec 15, 2010 3:06 UTC (Wed) by HelloWorld (guest, #56129) [Link]

No no, you misunderstand. It's not as bad as that. What destructor shared_ptr calls depends on the declared type of the argument in its constructor, not the type of the shared_ptr itself.

Whoa! That is certainly a behaviour I didn't expect. Other smart pointer classes like boost::scoped_ptr or std::auto_ptr don't do this, and I really can't think of a reason for making shared_ptr behave that way. Do you know of any rationale for this behaviour?

Apache resigns from the Java Community Process executive committee

Posted Dec 15, 2010 2:24 UTC (Wed) by HelloWorld (guest, #56129) [Link]

> Is that a flaw in shared_ptr or in the underlying language?
shared_ptr has nothing to do with it, the same thing would happen if you'd delete the pointer by hand. The problem stems from the fact Bar's destructor isn't virtual.

I guess the reason for not making destructors virtual by default is that this would be inconsistent with the rest of the language, as other methods aren't virtual by default either. In the very early days of C++, member functions existed but virtual member functions were introduced only later. At that point, Bjarne chose not to make methods virtual by default, but you had to use the virtual keyword to make them. I probably would have done it the other way around, as the worst thing a virtual method call can do is make your program a little slower, while making a non-virtual method call can cause severe bugs.

So, whether this is a flaw in the language depends on whom you ask.

Apache resigns from the Java Community Process executive committee

Posted Dec 15, 2010 1:41 UTC (Wed) by HelloWorld (guest, #56129) [Link] (12 responses)

It's possible to write correct code in C++, but it requires a *lot* of self-discipline. You can make all the same mistakes a C programmer can, plus a whole lot more.

I believe that this argument is a red herring for two reasons. The first is that it doesn't take into account how likely you are to make a certain typical C mistake in C++. For example, it's very easy to make a mess of dynamically allocated arrays in C, and while this is also possible in C++, you're much more unlikely to, as you'd probably just use a container class. The second is that if you do the C equivalent of the things that may cause bugs in a C++ program, you're at least as (and probably more) likely to make the same mistake. Your example would look something like this in C:

#include <string.h>
#include <stdlib.h>
struct Foo_vtbl {
  void (*destroy)();
};
struct Foo {
  struct Foo_vtbl *vtbl;
};
void destroy_Foo(struct Foo *f) {
}
struct Foo_vtbl Foo_vtbl = { &destroy_Foo };
void delete_Foo(struct Foo *f) {
  f->vtbl->destroy(f);
  free(f);
}
void construct_Foo(struct Foo *f) {
  f->vtbl = &Foo_vtbl;
}
struct Foo *new_Foo() {
  struct Foo *f = malloc(sizeof(struct Foo));
  construct_Foo(f);
  return f;
}

struct Bar_vtbl {
  struct Foo_vtbl foo_vtbl;
};
struct Bar {
  struct Foo foo;
  char *str;
};
void destroy_Bar(struct Bar *b) {
  free(b->str);
  b->foo.vtbl = &Foo_vtbl;
  destroy_Foo(&b->foo);
}
struct Bar_vtbl Bar_vtbl = { { &destroy_Bar} };
void delete_Bar(struct Bar *b) {
  b->foo.vtbl->destroy(b);
  free(b);
}
void construct_Bar(struct Bar *b) {
  construct_Foo((struct Foo *)b);
  b->foo.vtbl = (struct Foo_vtbl*) &Bar_vtbl;
  b->str = malloc(6);
  strcpy(b->str, "Hello");
}
struct Bar *new_Bar() {
  struct Bar *b = malloc(sizeof(struct Bar));
  construct_Bar(b);
  return b;
}

int main(void) {
  struct Foo *f = (struct Foo *)new_Bar();
  delete_Foo(f);
}

This is the kind of crap you need to write in order to do trivial object-oriented stuff in C. Note that making a destructor non-virtual is just as easy as in C++, just change

  f->vtbl->destroy(f);

  destroy_Foo(f);

in delete_Foo - it's still perfectly innocent-looking! And there are dozens of other opportunities for making silly mistakes in the above code that aren't there in the C++ version. So, while C++ certainly has its problems, I'd choose it over C any day of the week.

Apache resigns from the Java Community Process executive committee

Posted Dec 15, 2010 17:55 UTC (Wed) by cmccabe (guest, #60281) [Link] (11 responses)

Aaaaragh! It burns, it burns!

How about you read the kernel style guide and rewrite it as this:

> #include <stdlib.h>
> #include <string.h>
> 
> struct Foo {
>         /* foo stuff */
> };
> 
> struct Bar {
>         struct Foo f;
>         int b;
> };
> 
> int main(void) {
>         struct Foo *my_foo = malloc(sizeof(struct Bar));
>         memset(my_foo, 0, sizeof(struct Bar));
>         /* do stuff ... */
>         free(my_foo);
>         return 0;
> }

Apache resigns from the Java Community Process executive committee

Posted Dec 15, 2010 19:33 UTC (Wed) by HelloWorld (guest, #56129) [Link] (10 responses)

You're totally missing the point. As foom pointed out earlier, the case that you gave initially doesn't actually leak memory, as an int member doesn't require any cleanup to be performed. In order for it to leak memory, it needs to be an object of a class that requires cleanup, like std::string. And if you add such a member to your struct Bar, you need all the plumbing I've shown.

(formally, using delete with a base class pointer that points to an object of a derived class yields undefined behaviour (UB) unless the base class's destructor is virtual, but the memory is correctly freed in any implementation I know of, it's just that the destructor for the additional member in Bar isn't run -- which doesn't matter as int doesn't have a destructor. Also, your example also exhibits UB as soon as you want to use my_foo as a struct Bar* (which ought to be possible since it really does point to a struct Bar))

Apache resigns from the Java Community Process executive committee

Posted Dec 15, 2010 23:50 UTC (Wed) by cmccabe (guest, #60281) [Link] (9 responses)

> You're totally missing the point. As foom pointed out earlier, the case
> that you gave initially doesn't actually leak memory, as an int member
> doesn't require any cleanup to be performed. In order for it to leak
> memory, it needs to be an object of a class that requires cleanup, like
> std::string. And if you add such a member to your struct Bar, you need all
> the plumbing I've shown.

*You* are missing the point. Programming in both C and C++ requires strict adherence to certain conventions to make it practical. In C the convention is to have an alloc_foo() and a free_foo(). In C++, the conventions are more complicated (and numerous), but one of them involves using a base class with a virtual destructor.

> (formally, using delete with a base class pointer that points to an object
> of a derived class yields undefined behaviour (UB) unless the base class's
> destructor is virtual, but the memory is correctly freed in any
> implementation I know of, it's just that the destructor for the additional
> member in Bar isn't run -- which doesn't matter as int doesn't have a
> destructor

Yes, several things need to come together for the bad behavior to bubble to the surface-- putting "new" on a different line than the declaration of shared_ptr, a non-trivial destructor for Bar, a low-memory condition, and your most important customer attending the demo. Does that make you feel better, or worse?

> Also, your example also exhibits UB as soon as you want to use my_foo as a
> struct Bar* (which ought to be possible since it really does point to a
> struct Bar))

Wrong. There's nothing undefined about the behavior of typecasts in C.

In C, the address of the first data member is always equal to the address of the containing struct. So using my_foo as a struct Foo is fine. If you want to use it as a Bar (downcasting) you must use a typecast.

On a more fundamental level, inheritance is an overused technique. C++ experts like Scott Meyers advocate more use of composition, and less of inheritance. Unfortunately, languages like Java and C++ have the opposite bias, giving you all kinds of fancy syntax for inheritance, but almost none for composition.

For example, composition is the only safe way to extend the standard containers in the STL. (Partly this is because they have non-virtual destructors, and partly because the methods they contain may be implementation-dependent.) But if you try to use composition in this way, you'll have to write a wrapper class by hand that passes through every function call to the contained object. It's a tedious and manual process.

Apache resigns from the Java Community Process executive committee

Posted Dec 16, 2010 1:28 UTC (Thu) by HelloWorld (guest, #56129) [Link] (8 responses)

> *You* are missing the point. Programming in both C and C++ requires strict adherence to certain conventions to make it practical. In C the convention is to have an alloc_foo() and a free_foo(). In C++, the conventions are more complicated (and numerous),

No, they're not really. The cases you can deal with in such a simple manner are just as simple in C++ - you allocate with new and you free with delete, no need for virtual destructors. However, if you actually *need* a virtual destructor, then writing an equivalent program in C requires you to write all of that boilerplate code I've shown earlier.
The difference is not that C is somehow simpler than C++, it's that C++ provides solutions (perhaps not perfect ones) to problems that C doesn't deal with at all.

> Wrong. There's nothing undefined about the behavior of typecasts in C.
You're right, I was wrong in that respect.

> On a more fundamental level, inheritance is an overused technique. C++ experts like Scott Meyers advocate more use of composition, and less of inheritance. Unfortunately, languages like Java and C++ have the opposite bias, giving you all kinds of fancy syntax for inheritance, but almost none for composition.
What kind of "fancy syntax" for composition do you have in mind?

Apache resigns from the Java Community Process executive committee

Posted Dec 16, 2010 4:39 UTC (Thu) by cmccabe (guest, #60281) [Link] (7 responses)

Just so people don't think I only criticize C++, here are some subtle errors in C code:

> char buf[80];
> fgets(user_str, sizeof(buf), stdin);
> printf(user_str);

> extern int *my_array;
> /* "zero the array" */
> memset(my_array, 0, sizeof(my_array));

Anyway, to reiterate. C++ was never designed to be safer than C. Every time the designers of C++ had to choose between execution speed and safety, they chose execution speed. C++ is almost like a rapid application development kit for C.

The problem is, when you select execution speed and short development time as your two highest priorities, readability and code quality suffer. For a lot of applications (for example, the Linux kernel), that's simply not acceptable. C++ is still appropriate for many applications. For example, the computer games industry loves C++, despite all the new languages that have come out in the last few years.

> What kind of "fancy syntax" for composition do you have in mind?

At a minimum, C++ should offer something like Ruby does: the ability to create accessors for elements by adding a quick attribute in the variable declaration. For example:

> class Foo {
>  int bar : attr_reader
>  int baz : attr_reader, attr_writer
> }
>
> cout << my_foo.bar() << endl; // look ma, no boilerplate!

Personally, I'm going to explore Google Go a little bit more. It doesn't even have the concept of inheritance. Go just has "specifications" that say what methods a type must provide to meet the specification. Any type that has such methods can be used. Sort of like duck typing, but enforced at compile time and safe! And there is no "static type" vs. "dynamic type" misery, and no base classes teleporting random variables into the middle of your code.

Apache resigns from the Java Community Process executive committee

Posted Dec 21, 2010 0:54 UTC (Tue) by HelloWorld (guest, #56129) [Link] (6 responses)

Anyway, to reiterate. C++ was never designed to be safer than C. Every time the designers of C++ had to choose between execution speed and safety, they chose execution speed.

When you design a systems programming language, then that seems like a sensible thing to do.

The problem is, when you select execution speed and short development time as your two highest priorities, readability and code quality suffer.

Perhaps it's just me, but I think that putting "virtual" in front of a destructor is a lot more readable than implementing vtables by hand which looks like this.

At a minimum, C++ should offer something like Ruby does: the ability to create accessors for elements by adding a quick attribute in the variable declaration.

There is no special syntax for it, but on the other hand, returning a reference isn't very verbose (and you can use a macro to make it shorter).

Personally, I'm going to explore Google Go a little bit more. It doesn't even have the concept of inheritance. Go just has "specifications" that say what methods a type must provide to meet the specification. Any type that has such methods can be used. Sort of like duck typing, but enforced at compile time and safe! And there is no "static type" vs. "dynamic type" misery, and no base classes teleporting random variables into the middle of your code.

Well, Go may be a nice language but sometimes you don't want a garbage collector.

Apache resigns from the Java Community Process executive committee

Posted Dec 21, 2010 21:19 UTC (Tue) by cmccabe (guest, #60281) [Link] (5 responses)

Perhaps it's just me, but I think that putting "virtual" in front of a destructor is a lot more readable than implementing vtables by hand which looks like this.

You're missing the point. vtables can be useful, but you just don't need them that often. The fact that there is a special syntax in C++ encourages people to write bad code.

There are numerous examples of vtables in the Linux kernel. Usually it's just as simple as a struct with function pointers and a registration function that's called on that struct.

C++'s special syntax for vtables makes it quicker to create them, but does it make it easier to do it correctly? In my experience, most C++ programmers don't know the hidden gotchas that lurk everywhere once you first type "virtual."

For example, what's the problem here?

class Foo {
public:
  virtual ~Foo() { log("destroying Foo."); }
protected:
  virtual void log(const std::string & foo) { }
};

class LoggedFoo : public Foo {
public:
protected:
  virtual void log(const std::string & str) {
    std::cout << "logging important message " << str << std::endl;
  }
};

There is no special syntax for it, but on the other hand, returning a reference isn't very verbose (and you can use a macro to make it shorter).

The minimum accessor length I can think of is something like this:

const Foo & foo() const { return _foo; }

That's a lot of typing just for one data member. The fact is, they really blew it by not having a better syntax for this-- in my opinion. Also, Java has the same problem but even worse.

Well, Go may be a nice language but sometimes you don't want a garbage collector.

If you don't want a garbage collector, why not just write it in C? C++ represents the awkward, error-prone adolescence of higher-level languages, not their future.

Apache resigns from the Java Community Process executive committee

Posted Dec 21, 2010 23:07 UTC (Tue) by HelloWorld (guest, #56129) [Link] (4 responses)

You're missing the point. vtables can be useful, but you just don't need them that often.

The funny thing is that you wrote the rebuttal to this statement yourself only a few lines later: "There are numerous examples of vtables in the Linux kernel".

The fact that there is a special syntax in C++ encourages people to write bad code.

Limiting the language in order to prevent programmers from writing bad code never worked and it never will, since bad programmers will find other ways to write a bad program. On the other hand, you're making life harder for the people who are able to use advanced features in the language sensibly. This looks like a very bad tradeoff to me.

C++'s special syntax for vtables makes it quicker to create them, but does it make it easier to do it correctly? In my experience, most C++ programmers don't know the hidden gotchas that lurk everywhere once you first type "virtual." For example, what's the problem here?
class Foo {
public:
  virtual ~Foo() { log("destroying Foo."); }
protected:
  virtual void log(const std::string & foo) { }
};

class LoggedFoo : public Foo {
public:
protected:
  virtual void log(const std::string & str) {
    std::cout << "logging important message " << str << std::endl;
  }
};

I don't know what you expected the program to do, so how am I supposed to know what you consider to be a problem? Perhaps you meant that ~Foo will call Foo::log and not LoggedFoo::log. I believe that this is a Good Thing. LoggedFoo may have introduced a new meber variable x, and if LoggedFoo::log would use x somewhere, it'd blow up when called by ~Foo, as x would already have been destroyed at that point.

If you don't want a garbage collector, why not just write it in C?

Because C doesn't offer me the features I want. I want type-safe containers (read: templates), I want OOP, I want exceptions and I want destructors. C doesn't have those, and I actively hate C for this (amongst other things).

C++ represents the awkward, error-prone adolescence of higher-level languages, not their future.

No, C++ was never meant to rival high level languages. When it was designed, high-level languages like Smalltalk existed, and Bjarne deliberately designed C++ differently, because he wanted to do low-level work.
Of course, C++ has its share of problems, many of which are either due to its low-level nature or inherited by C (weak type system, bad syntax, horrible preprocessor), so I'd certainly pick a higher-level language over C++ when that is possible. But if the choice is between C and C++, I know what to choose.

Apache resigns from the Java Community Process executive committee

Posted Dec 22, 2010 11:43 UTC (Wed) by cmccabe (guest, #60281) [Link] (3 responses)

> The funny thing is that you wrote the rebuttal to this statement yourself
> only a few lines later: "There are numerous examples of vtables in the
> Linux kernel".

I think we both know that the real question is not how many X the Linux kernel source has, but how many X per lines of code. By that measure, vtables are used sparingly and tastefully.

> Limiting the language in order to prevent programmers from writing bad
> code never worked and it never will, since bad programmers will find other
> ways to write a bad program. On the other hand, you're making life harder
> for the people who are able to use advanced features in the language
> sensibly. This looks like a very bad tradeoff to me.

My point wasn't about limiting the language. I think we all know that C can be used to do anything C++ can do, and vice versa. The question is, what does the feature set of the language encourage you to do? Is it in good taste? Does it encourage you to write things in a readable way, or in an unnecessarily complex and formal way? Do the features work well together, or are there some that can't safely be used in combination (or even separately?)

> [snip discussion of virtual function calls in base constructor/destructor]

Congrats, you know the solution to this one. Now be careful, because the behavior is different in Java and C#.

Apache resigns from the Java Community Process executive committee

Posted Dec 22, 2010 14:43 UTC (Wed) by paulj (subscriber, #341) [Link] (2 responses)

To be fair, non-virtual methods are, we now know, extremely dangerous and inconsistent with the type-safety of inheritance (some of which was developed with and even after the development of C++). That C++ even allows them is perhaps a historical curiosity. One of a number of misfeatures in C++, where new language features were added before they were fully understood, leaving vestigial dangers waiting to trip up programmers. I like the other commentator's description of C++ being "the awkward, error-prone adolescence of higher-level languages".

Apache resigns from the Java Community Process executive committee

Posted Dec 25, 2010 4:46 UTC (Sat) by foom (subscriber, #14868) [Link] (1 responses)

> To be fair, non-virtual methods are, we now know, extremely dangerous [...]. That C++ even allows them is perhaps a historical curiosity.

Absolutely not a historical curiosity! I can't imagine using a C++-like language that didn't allow non-virtual members. Being able to do OOP with *zero* runtime overhead is a killer feature!

There's certainly place in the world for languages like Python too (which I do like, despite its horrific slowness), but C++ without non-virtual methods would just be sad.

Apache resigns from the Java Community Process executive committee

Posted Dec 25, 2010 10:50 UTC (Sat) by paulj (subscriber, #341) [Link]

It's a killer feature in terms of weird bugs, yes. If non-virtual methods were also not overridable, then perhaps it'd be a useful thing...

Apache resigns from the Java Community Process executive committee

Posted Dec 13, 2010 21:22 UTC (Mon) by nix (subscriber, #2304) [Link]

Performance when writing data structures and other low-level code. I've seen 40% speedups through jamming small items directly into pointer fields in various data structures over the years (both due to reducing malloc() load and due to reducing cache thrashing). Now that Moore's Law is broken and cores are not speeding up, this would start to be important, I'd say.

Apache resigns from the Java Community Process executive committee

Posted Dec 12, 2010 15:03 UTC (Sun) by HelloWorld (guest, #56129) [Link]

> C++ evolved the same way; originally, it was just a preprocessor called CFront that generated C code.
CFront never was any sort of "preprocessor", it always was a proper compiler which just happened to generate C instead of assembly language, as anything else wouldn't have been portable enough.

Apache resigns from the Java Community Process executive committee

Posted Dec 13, 2010 9:56 UTC (Mon) by jmalcolm (subscriber, #8876) [Link]

The Vala eco-system certainly makes it seem that most Vala developers live in GTK+ land.

That said, there is really nothing in Vala that ties it to GTK+. What it is tied to is GLib, or more specifically GObject.

I would think that using Vala in an environment that assumes a different base object (like NSObject in OS X or qobject in KDE) would be a bit of work as a result.

Apache resigns from the Java Community Process executive committee

Posted Dec 11, 2010 21:51 UTC (Sat) by cmccabe (guest, #60281) [Link] (3 responses)

> If Apache leaves Java behind then it should find or sponsor a patent free
> alternative language. An interpreted version of C++ would probably be
> least painful. I am not a C++ fan but what is closer to Java? Java has a
> huge memory foot print, I would welcome a reimagined alternative that is
> leaner, meaner, and faster.

Google Go?

It has a static type system, garbage collection, and a sane approach to concurrency.

Apache resigns from the Java Community Process executive committee

Posted Dec 11, 2010 23:09 UTC (Sat) by kripkenstein (guest, #43281) [Link] (2 responses)

> Google Go?

> It has a static type system, garbage collection, and a sane approach to concurrency.

Go is interesting, but among the emerging languages in that area, I would suggest Rust. It has more emphasis on safety and given it's explicit mutability, should be more optimizable.

Apache resigns from the Java Community Process executive committee

Posted Dec 13, 2010 3:44 UTC (Mon) by cmccabe (guest, #60281) [Link] (1 responses)

Rust sounds interesting, I'll have to check it out.

From everything I've read about Google Go, it really seems like a very practical language designed by people who have a huge amount of experience building actual systems. While reading through the examples, I had to smile, because they fixed a lot of my biggest gripes with C and C++. These are the language features that every practical programmer has stubbed his toe on, and hated ever after.

> It has more emphasis on safety and given it's explicit mutability, should
> be more optimizable

Speaking as someone who wrote a (toy) compiler once, the big problem in optimizing C/C++ is the "aliasing problem"-- the difficulty of determining if a location in memory has been modified since it was last fetched from memory.

From what I've read, the general idea in Go (and presumably Rust as well) is "don't communicate by sharing memory, share memory by communicating." If you're just passing objects by value on channels, I don't think that presents the same difficulties to the optimizer. Go does have pointers, of course, but I don't think that they get used nearly as much as in C/C++. Anyway, I'm still learning about this!

Apache resigns from the Java Community Process executive committee

Posted Dec 13, 2010 4:51 UTC (Mon) by kripkenstein (guest, #43281) [Link]

> Speaking as someone who wrote a (toy) compiler once, the big problem in optimizing C/C++ is the "aliasing problem"-- the difficulty of determining if a location in memory has been modified since it was last fetched from memory.

> From what I've read, the general idea in Go (and presumably Rust as well) is "don't communicate by sharing memory, share memory by communicating."

That's true, but the aliasing problem is only the big problem since a lot of other stuff isn't possible. Rust, for example, makes everything immutable by default, which opens up entirely new avenues for optimization that aren't available in C/C++, Java, Go, C#, etc. Whereas functional languages like Haskell make very good use of immutability in their optimizations.

Apache resigns from the Java Community Process executive committee

Posted Dec 13, 2010 9:41 UTC (Mon) by jmalcolm (subscriber, #8876) [Link] (2 responses)

"Mono is at least as encumbered by patents as Java is."

We differ in our interpretation of "at least". The Microsoft Community Promise makes a great deal of Mono "explicitly" unencumbered by Microsoft patents. This includes the entire CLR (equivalent of the JVM) and the entire C# language (the equivalent of um...Java).

In addition, Microsoft has released a great deal of software under Apache version 2.0 (ironically) which includes an explicit patent grant. The list of such software includes ASP.NET MVC, MEF, IronRuby, IronPython, and F#.

There are still parts of the .NET class libraries that are not covered by these two options though so you would need to implement free alternatives to these. For example, instead of Windows Forms or Windows Presentation Foundation you would need to use something like GTK#.

Still, I would not say Mono is "at least" as encumbered as Java. Not as I see it anyway.

Whether or not you like Mono is another matter. I would assume that somebody comparing it to a disease does not.

Oh, and the people that say that the MCP is not legally enforceable are complete wing-nuts. First of all, it definitely is (legal argument omitted as long and off-topic here), and second of all Microsoft has said in writing that it intends it to be enforceable and permanent.

Apache resigns from the Java Community Process executive committee

Posted Dec 13, 2010 21:12 UTC (Mon) by RogerOdle (subscriber, #60791) [Link] (1 responses)

Microsoft has a long history of not playing nice. They would love to see major open source projects become depended on mono. They will use the embrace and extend thing by adding features that are not covered by their false promises. They may not cause open source projects to fail entirely. They may make them crash unexpectedly or run slow. At the least, they will take steps to make open source projects look unprofessional. People are more often judged by what they do, not what they say. Microsoft promises are so much wind.

Why should the world commit itself to the ideas of one company? It is long past time that open source established its own solution independent of those that are proprietary, overly complex, and legally vague. Now may be the perfect time. Java and dot-net were conceived before cloud computing and are not optimised for that environment. The open-source community can take the initiative by developing a cloud-centric language with a supporting multi-hosted virtual machine. The machine could run on one computer but it could also transparently scale upwards by adding more networked computers to the same runtime. It would be an answer for everything that is Java or dot-net are now and a path to the future that neither Java nor dot-net have reached. Both Google and Apache have reasons to support such an initiative.

Apache resigns from the Java Community Process executive committee

Posted Dec 13, 2010 22:38 UTC (Mon) by Trelane (guest, #56877) [Link]

http://www.parrot.org/news/2010/Parrot-2.10.0

ftp://ftp.uni-siegen.de/pub/parrot-docs/html/docs/overvie...
ftp://ftp.uni-siegen.de/pub/parrot-docs/html/index.html