Google bails out of JavaOne [LWN.net]

It should probably surprise nobody that Google has announced that its employees will not be attending JavaOne this year. "So were sad to announce that we won't be able to present at JavaOne this year. We wish that we could, but Oracles recent lawsuit against Google and open source has made it impossible for us to freely share our thoughts about the future of Java and open source generally."

to post comments

See them at Apachecon?

Posted Aug 27, 2010 19:13 UTC (Fri) by dmarti (subscriber, #11625) [Link] (14 responses)

Looks like Apachecon, coming up in November is the place to be for Java anyway.

See them at Apachecon?

Posted Aug 27, 2010 20:08 UTC (Fri) by rahvin (guest, #16953) [Link] (13 responses)

IMO the only place to be is away from Java. Oracle has demonstrated a desire and willingness to use the Java patents. That should kill the Java FOSS community dead IMO, the risks are simply too high.

See them at Apachecon?

Posted Aug 27, 2010 20:55 UTC (Fri) by MisterIO (guest, #36192) [Link] (12 responses)

Could they attack code written to work on the OpenJDK too? Or could they even stop the OpenJDK development? It seems to me like nobody really explained this clearly, leving everything in some kind of foggy confusion.

See them at Apachecon?

Posted Aug 27, 2010 21:53 UTC (Fri) by drag (guest, #31333) [Link] (11 responses)

They would not be able to stop the creation of OpenJDK anymore then MPEG-LA could stop people from developing x264.

Patents do not restrict the creation of objects of private property, they restrict the use of your private property. That is, I believe, that only when people try to distribute and use OpenJDK is when Oracle can be asshats.

IANAL

Of course, that would not stop them from writing dick-ish letters and threatening everybody.

See them at Apachecon?

Posted Aug 27, 2010 22:09 UTC (Fri) by Trelane (guest, #56877) [Link] (10 responses)

Patents do not restrict the creation of objects of private property, they restrict the use of your private property.

Yes, they do.

Quot the U.S. Patent Office:

Patents ...provide exclusive rights to make, use, import, sell and offer for sale the invention for up to 20 years.

I've bolded section that contradicts your claim.

(not trying to say anything with the "kids' page"; it was merely the first hit I found)

See them at Apachecon?

Posted Aug 28, 2010 7:50 UTC (Sat) by elanthis (guest, #6227) [Link] (9 responses)

Software is different, though. Source code is not the invention. The working algorithm is. This is why many patented pieces of software are often distributed in a source-only form. The source is legal, the binary code is not.

Never mind that these are one and the same, as binary code is just a translation from one coding (ASCII text) to another (machine code). Never mind that any binary code can be turned back into source code (albeit not usually the same as the original, due to loss of information during the source->binary translation).

IANAL, just commenting on what I've observed other projects have done... although those people probably aren't lawyers either.

There are precendent which is way, way, more powerful then "other FOSS program"

Posted Aug 28, 2010 11:50 UTC (Sat) by khim (subscriber, #9252) [Link] (1 responses)

If you recall for a long-long time "string crypto" was export-restricted. It was impossible to export it yet PGP existed in two forms: US-only PGP and non-US PGPi. How that happened? Well, the source code was printed as book, this book was exported (the usual way: it was legally printed book, first amendment protects this right). then scanned and compiled.

Of course electronic version of source code is much closer to binary, so YMMV, but usually it's assumed that source code does not infringe if it can not be executed directly (the question about Python and JavaScript programs is still open).

There are precendent which is way, way, more powerful then "other FOSS program"

Posted Aug 29, 2010 1:53 UTC (Sun) by riddochc (guest, #43) [Link]

That wasn't a patent issue, though. There were/are different laws relating to cryptography.

See them at Apachecon?

Posted Aug 28, 2010 15:15 UTC (Sat) by Trelane (guest, #56877) [Link] (6 responses)

Source code is not the invention. The working algorithm is.

Correct. Making software from the algorithm is making that algorithmm into a product, and thus runs afoul of patent law (see above).

The source is legal, the binary code is not.

You'll need to provide an external, trusted (varies from recipient to recipient) source to back you up on this. Everything I can see and understand thus far says that source code can infringe on a patent. IANAL, tho, so perhaps someone who is (or is close to, e.g. bkuhn) can weigh in (with the understanding that such input would Not Be Legal Advice ;)

See them at Apachecon?

Posted Aug 30, 2010 0:00 UTC (Mon) by gmaxwell (guest, #30048) [Link] (3 responses)

It sounds like some of the other crazy things software developers sometimes believe about the law.

I'd asked my SO (who is a patent agent) for a view on this a while back and got back a 'that sounds like bullshit, but if it specific facts and the caselaw was such that you somehow could escape an infringement claim you almost certainly could not escape a contributory infringement or inducement claim'.

I mean, sure, if someone is trying to hit you for infringement you'll argue that, and I wish you well. But I doubt your prospects will be good. Courts are _usually_ pretty happy to see right through most kinds of shell games, except when the law specifically direct them otherwise. "I didn't really pull the trigger, your honor. I set a radioactive decay detector on a sample of uranium and that was connected to a row of dominoes [...] ultimately firing the gun. As you can see, I had no control over who lived and died and as such you must find me not guilty." "Guilty." "Argh!"

The PGP ITAR stuff is an entirely different set of laws, and you often can't generalize across the law like that.

See them at Apachecon?

Posted Aug 30, 2010 17:03 UTC (Mon) by Trelane (guest, #56877) [Link] (2 responses)

Thanks for the interesting post.

Pardon my ignorance, but what are "contributory infringement" and "inducement" claims?

Thanks.

See them at Apachecon?

Posted Aug 30, 2010 17:31 UTC (Mon) by gmaxwell (guest, #30048) [Link] (1 responses)

In the US, see 35 U.S.C. §271 b/c/f, obviously this is all made more complicated by the standards and interpretations invented by the courts but this should give you an idea.

See them at Apachecon?

Posted Aug 30, 2010 17:37 UTC (Mon) by Trelane (guest, #56877) [Link]

ah, indeedy so. Thanks!

See them at Apachecon?

Posted Aug 31, 2010 7:33 UTC (Tue) by dgm (subscriber, #49227) [Link]

I'm aware this is irrelevant more often than not, but common sense says source code, being a textual description of (part of?) the "invention", should not infringe the patent any more than a drawing or textual description of a physical patented device.

See them at Apachecon?

Posted Sep 7, 2010 22:54 UTC (Tue) by mishad (guest, #69757) [Link]

I believe the reasoning is that, since 'pure software' is not patentable even in the US, software patents are described as running on a physical machine. This allows the patent to meet the 'physical tranformation' test for subject matter eligibility. But it also makes the 'execution on a computer and essential element of the claims, which means that non-executable versions of the software - e.g. C code - do not read on those claims so cannot be infringing.

I have no idea whether code in scripting/interpreted languages can use this get-out clause.

In any case, its extremely likely that, in the course of developing the software, the developer will have compiled and run it at least once, so I'm not sure how much practical defence this would provide.

IANAL etc etc.

Google bails out of JavaOne

Posted Aug 28, 2010 1:10 UTC (Sat) by djzort (guest, #57189) [Link] (83 responses)

there are so many other languages with better OO implementations than java that are more cross platform, dont have stupid memory handling and with huge libraries (or 'classes' if you like that term) of functions to draw upon - why waste any more time on java?

object code hasnt proved all that beneficial in the real world and given that java mainly runs as a web service there isnt much argument about keeping source code secret.

perl and python will love you back more than java every will :)

Google bails out of JavaOne

Posted Aug 28, 2010 2:25 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (35 responses)

"there are so many other languages with better OO implementations than java that are more cross platform, dont have stupid memory handling and with huge libraries (or 'classes' if you like that term) of functions to draw upon - why waste any more time on java?"

I'd be interested to hear about these languages. One caveat: they must have static typing. So Python and Perl are out.

Google bails out of JavaOne

Posted Aug 28, 2010 2:28 UTC (Sat) by Trelane (guest, #56877) [Link]

Perl is out anyway. ;)

(well, native perl. Moose sucks much much less).

Google bails out of JavaOne

Posted Aug 28, 2010 4:14 UTC (Sat) by flewellyn (subscriber, #5047) [Link] (1 responses)

Do they have to merely have static typing, or do they have to require it with mandatory declarations?

If the former, then there's stuff like OCaml, Boo for the CLI, or Common Lisp. The first two use type inference, and CL has type declarations which are used for optimization purposes.

If you want mandatory declarations, though, well...if you want C++ you know where to find it.

Google bails out of JavaOne

Posted Aug 28, 2010 4:49 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

Well, if I have to use CLI, I'd use C# instead of Boo. Or Nemerle (which is a quite nice language).

OCaml has problems with libraries - most of OCaml libs are just wrappers around native libraries. Also, OCaml has other problems.

You also forgot to mention D and Haskell :)

Common Lisp is, well, ancient. Besides, I hate it :)

Google bails out of JavaOne

Posted Aug 28, 2010 4:15 UTC (Sat) by tnoo (subscriber, #20427) [Link] (30 responses)

> One caveat: they must have static typing. So Python and Perl are out.

Care to elaborate? Why *must* they have static typing?

Google bails out of JavaOne

Posted Aug 28, 2010 4:52 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (25 responses)

Because static typing is very useful. To ones who know how to use it.

For example, static typing allows to use precise automatic refactorings and code navigation. Which is quite handy in large projects.

Dynamic languages require you to write test cases for all of your code, or it becomes unmaintainable quite soon. So in practice in fairly large projects there's little of advantage from flexibility of dynamic languages.

Google bails out of JavaOne

Posted Aug 28, 2010 5:42 UTC (Sat) by kripkenstein (guest, #43281) [Link] (24 responses)

> Dynamic languages require you to write test cases for all of your code, or it becomes unmaintainable quite soon. So in practice in fairly large projects there's little of advantage from flexibility of dynamic languages.

This has been endlessly debated everywhere, and not really ontopic. But, just to present the contrasting opinion: You need high test coverage for static languages as well; about the same amount in fact. And large projects (I've worked on several) most certainly do benefit from the flexibility of dynamic languages.

Google bails out of JavaOne

Posted Aug 29, 2010 5:39 UTC (Sun) by Ze (guest, #54182) [Link] (23 responses)

>This has been endlessly debated everywhere, and not really ontopic. But, just to present the contrasting opinion: You need high test coverage for static languages as well; about the same amount in fact. And large projects (I've worked on several) most certainly do benefit from the flexibility of dynamic languages.

Simple put your wrong :) static type checking means the compiler automatically does type checking test cases saving you having to write them yourself.

Statically typed languages with templates and type inference give all the benefits of dynamic typed languages without the downside and cost of type checking at runtime.

Personally I can't see why you'd want to deal with the hassles of creating test cases for dynamically typed languages when the compiler can do it for you and does a better job of it.

Google bails out of JavaOne

Posted Aug 29, 2010 17:28 UTC (Sun) by pboddie (guest, #50784) [Link] (22 responses)

Simple put your wrong :)

Whose wrong are you referring to?

static type checking means the compiler automatically does type checking test cases saving you having to write them yourself.

This assumes that the type system is expressive enough to cover the semantic differences between values belonging to a particular type. In fact, in most statically typed languages, the type system doesn't seek to understand the differences between values - for example, that the two strings "update" and "replace" (or their equivalents in an enumeration) are used to control a program in completely different ways - and thus the potential remains for various classes of bugs or erroneous behaviour.

Statically typed languages with templates and type inference give all the benefits of dynamic typed languages without the downside and cost of type checking at runtime.

They don't give the benefits of being relatively easy to write or necessarily promoting incremental development.

Personally I can't see why you'd want to deal with the hassles of creating test cases for dynamically typed languages when the compiler can do it for you and does a better job of it.

If you think that test cases are all about testing the types of things and nothing else, then you've managed to focus on one tiny area where testing may be employed whilst ignoring the many legitimate uses of testing that also apply to statically typed languages. "The compiler produced an executable!" is not a substitute for proper testing.

Google bails out of JavaOne

Posted Aug 30, 2010 2:11 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (21 responses)

"They don't give the benefits of being relatively easy to write or necessarily promoting incremental development."

Have you ever seen a good Java developer with IntelliJ IDEA? Nothing, absolutely NOTHING comes even close in flexibility for incremental development (well, maybe C# with ReSharper). One can easily with several keypresses do major refactorings, unthinkable in other languages.

Like, want to add a parameter to a function? NP, IDEA will highlight all places where it's used and will try to guess the correct local variable which I'd like to pass as a parameter.

Renaming? Works without second thoughts, for all types of objects (fields, methods, classes, etc.). Then there's 'structural replace' - the same thing as Cochinelle ( http://lwn.net/Articles/315686/ ), but for Java and with more capabilities.

Code navigation? Like a breeze - it's possible to find all usages of an object (method, field, class) with one keypress. And it works _instantly_. It's so fast that IDEA actually has functionality to highlight globally unused methods.

Also, I continuously use 'introduce variable', 'extract method', 'extract method object' and lots of other refactorings. It's really amazing how it's possible to slice and dice code.

All of the above works just fine in projects with gigabytes of source code.

Besides, with JavaRebel I get dynamic code updates. So even this advantage of dynamic languages is negated.

Google bails out of JavaOne

Posted Aug 30, 2010 11:46 UTC (Mon) by pboddie (guest, #50784) [Link] (20 responses)

Have you ever seen a good Java developer with IntelliJ IDEA?

Not recently. I have seen various Java IDEs in action over the years, and it was always like watching someone typing through treacle with red, squiggly lines under half the code on the page.

Nothing, absolutely NOTHING comes even close in flexibility for incremental development (well, maybe C# with ReSharper). One can easily with several keypresses do major refactorings, unthinkable in other languages.

It's possible that I mean something else when I refer to "incremental development": that you start out with a vague idea of what you want and then refine it, but you aren't forced into spelling out a rigid type hierarchy if you don't want to. Sure, refactoring is helpful when you have to overhaul that rigid type hierarchy, and I've often wanted to improve the refactoring possibilities in Python, but then again I can get pretty far with a class/function/method search.

But anyway, the argument for "Java plus tools" and against dynamic languages is nothing new: it's like advocating using a JCB digger for all earth-moving tasks and then taking it out to do the gardening.

Google bails out of JavaOne

Posted Aug 30, 2010 14:31 UTC (Mon) by lenov (guest, #15428) [Link] (11 responses)

" Have you ever seen a good Java developer with IntelliJ IDEA?

Not recently. I have seen various Java IDEs in action over the years, and it was always like watching someone typing through treacle with red, squiggly lines under half the code on the page."

This is ridiculous. I have seen developers assembling entire applications in a day with Java + IntelliJ IDEA and Eclipse.

I don't understand this thread. LWN is usually full of knowledgeable, reasonably argumentative. But this thread looks like some kind of religious war against Java by ignorant script kiddies playing the geeks. As if attacking Java the language, would dissociate people from the "evil Oracle".

This is nonsense. A huge amount of code exists in Java, in about every single aspect of computing from embedding systems to website, going through various productivity tools. Even if Oracle would win (by that I do not mean the suits, that are ridiculous, but Android dropping Java), which I do not think will, this will not affect significantly the use of Java until years, only because of the legacy.

It's easy, actually...

Posted Aug 30, 2010 23:17 UTC (Mon) by khim (subscriber, #9252) [Link] (6 responses)

I don't understand this thread. LWN is usually full of knowledgeable, reasonably argumentative. But this thread looks like some kind of religious war against Java by ignorant script kiddies playing the geeks. As if attacking Java the language, would dissociate people from the "evil Oracle".

There are many reasons. First of all LWN people are FOSS people and not Java people. Java people and FOSS people were separated for a long time because of Sun's policy and while in last few years the wall started to be less and less pronounced it's still there. And now Oracle made sure this wall will be resurrected and Java will be relegated to "Cobol of XXI centory" rank. Of course people will deride Java: they don't know it, they don't like it - how can anyone discuss anything under this circumstances?

My own POV is that Java is horrible language, but Java IDEs are superb and they almost (but not quite) compensate for the shortcomings of Java.

This being said it does not actually explain why Java programmers routinely produce bloated memory hogs while both Python and C++ programmers produce small and nimble programs (albeit Java programmers produce their crap faster, I must admit that). This is especially strange because Python must be slooow... but somehow in my experience Python programs are faster then Java equivalent. Sure, Python programs often include vital components written in C/C++ to save both memory and time - but it does not change the end result.

A huge amount of code exists in Java, in about every single aspect of computing from embedding systems to website, going through various productivity tools.

Sorry, but no. Java only exist in enterprise and where managers were able to shove it (Java ME, BD-ROM, etc). When the programmers are given choice in these embedded systems they tend to avoid Java like plague. I don't know exactly why Java creations are bloated slow hogs, but that's the case.

Even if Oracle would win (by that I do not mean the suits, that are ridiculous, but Android dropping Java), which I do not think will, this will not affect significantly the use of Java until years, only because of the legacy.

Agree 100%. Java is today's Cobol and like the original Cobol Java will be with us for a long, long time. It does not mean it'll be used in new projects much - and Oracle can make sure it'll be legacy sooner rather then later.

It's easy, actually...

Posted Aug 31, 2010 2:40 UTC (Tue) by sbishop (guest, #33061) [Link]

Alright. You've made your point: you don't understand what you're talking about. Please quit clogging up my comment feed. Thank you.

It's easy, actually...

Posted Aug 31, 2010 6:11 UTC (Tue) by lenov (guest, #15428) [Link] (4 responses)

"First of all LWN people are FOSS people and not Java people. Java people and FOSS people were separated for a long time because of Sun's policy and while in last few years the wall started to be less and less pronounced it's still there. And now Oracle made sure this wall will be resurrected"

Who am-I then? I am on LWN, aren't I? And I have been here for years. As a matter of fact, every single line of code I wrote for the last 13 years has been under GPL. Every single line of code produced in my group, 95% being in Java, is under GPL. And my organisation has a policy that requires all code to be GPL-compatible. It comprises about 100 people spitting out Java code the whole day. All GPL-compatible.

"A huge amount of code exists in Java"

Sorry, but no. Java only exist in enterprise and where managers were able to shove it (Java ME, BD-ROM, etc). "

Sorry but you do not know what you are talking about. I am not part of a commercial company. Java is everywhere around here. See my other posts. Maybe you should accept the fact that you do not know everything. You are working in a certain domain/environment, and maybe there, Java is not a language of choice. But there are places where it is. And I am not a Java Zelot. I started with C, became a Perl fan, and now my group used mostly Python and Java. My point is not to praise Java.

Well, if you are so sure it's not just enterprise then it's easy to prove, right

Posted Aug 31, 2010 9:18 UTC (Tue) by khim (subscriber, #9252) [Link] (3 responses)

Who am-I then?

Opportunist, I presume.

I am on LWN, aren't I? And I have been here for years.

Well, Java people tried to coopt FOSS people for years. When FOSS people pointed out that Java is a trap Java people explained that it's not a big deal because there are lots of free Java (funny how the same approach of Adobe is universally hated and Flex-developers are usually despised while Java people always tried to pretend "they are FOSS people too"). Not unlike KDE spat, really. Few years ago Sun finally decided to free Java and the wall started to crumble: FOSS distributions started to allow Java packages, there were even talks that Vala is bad idea because we have Java, etc. But Oracle stopped and reversed it to a huge degree.

As a matter of fact, every single line of code I wrote for the last 13 years has been under GPL. Every single line of code produced in my group, 95% being in Java, is under GPL.

Well, that's what amazes me the most in Java people: they produce lots of free code, they try to play friends with FOSS community, yet they are happy to build the castle on the sand (proprietary base owned initially by Sun and later by Oracle). This looks like FOSS camp: we use GPL because it's good business strategy, we don't care about freedom at all. Yet Java people are often becoming angry when they are excluded from FOSS community. But actions speak louder than words and because of "original sin" FOSS community will perceive Java people as outsiders for a long, long, long time. C/C++ people are different: while it's true that many of them started with proprietary compilers and proprietary tools they embraced free replacement (GCC) wholeheartedly - but Java people never actually accepted free Java (before Android, that is). I don't know how many times I've heard from Java community "stop wasting our time with your inferior tools" (or words to that effect) when GCJ, Kaffe or any other free replacement was mentioned. This put Java firmly in "people who don't care about freedom" category - and that category lies outside of FOSS community.

That's how today we have two communities: "proper FOSS" community and "Java community". People from second camp perceive themselves as parts of FOSS community, but people from first camp rarely accede such privilege to them. When RedHat bought JBoss it was perceived as betrayal at first but then RedHat redeemed itself with it's IcedTea work. But release of IcedTea (and later OpenJDK) only started healing the chasm between FOSS community and Java community. It's slow process: KDE people are still not perceived as "fully FOSS people" even if their "original sin" was rectified by Trolltech and Nokia long ago. This is easy to understand: former slaves which fought for freedom and obtained it with blood and tears will long view complacent slaves who were freed just because lord decided that he does not like to keep these particular slaves as slaves with suspicion.

Sorry but you do not know what you are talking about.

I hear this from Java people a lot. But somehow proof never materializes. If Java is "everywhere" then it should be easy to point on the concrete examples, right. Where are they? It's easy to point to these monstrous bloated "enterprise solutions", but if you take a wider look on where FOSS thrives it's hard to see any Java there. Mobile? It was mostly used by "enterprise-oriented Blackberry" while "Java for everyone" (JavaME) was not all that popular and shrank fast. Network equipment? Well, there are some tools where Java is used for configuration - and it's almost as lame as IE6-only HTML. The only place where Java hits the normal person today is bank authentication and even there it becomes less and less popular. So... if we exclude enterprise and wannabe enterprise solutions, then... where is Java? Please don't answer with "you don't know anything", if it's some important component then surely it's known to everyone who deals with this technology...

I am not part of a commercial company. Java is everywhere around here.

And here is... where exactly? How many millions of users are using your technologies?

Java is too heavy for most users. Where you have power to spare it's not as important - and there Java is popular. But these are small niches: Enterprise, HPC, may be some science. Where price of computer is not important because it's attached to some uber-expensive piece. But where people actually care about efficiency... Java is quite scarce.

You are working in a certain domain/environment, and maybe there, Java is not a language of choice. But there are places where it is.

Actually where I work Java is quite popular. On "big iron". Where we can easily add the hardware to compensate for waste generated by Java. But on client side... only Android developers are using Java - and that's not real Java, it's slightly different beast...

Well, if you are so sure it's not just enterprise then it's easy to prove, right

Posted Aug 31, 2010 16:33 UTC (Tue) by lenov (guest, #15428) [Link] (1 responses)

" Who am-I then?

Opportunist, I presume."

Is insulting people your only way of interaction, or is-this just on LWN?

"Well, Java people tried to coopt FOSS people for years"

What? What do-you mean by "Java people"? What is a Java person? I started my programming life with Pascal, then moved to Labview, then C, then Perl and now I am hardly coding anymore but the people I supervise are using Python and Java (and I do not mention LaTeX and other FOSS efforts outside strictly programming languages). Who do-you think you are to categorize people like that? I am not talking about the current thread here. Seriously, you must think a bit about the way you view the world and treat people.

"Well, that's what amazes me the most in Java people: they produce lots of free code, they try to play friends with FOSS community,"

Here we go again. "Java People" "play friends with FOSS community". WTF??!!! Except if you are RMS, I probably produced FOSS while you did not even know how to program. Play friends with FOSS community!!! To me!!! Who introduced FOSS in about every place I went because they never heard of it. Jeez you have a very very high opinion of yourself don't you?

"and because of "original sin" FOSS community will perceive Java people as outsiders for a long, long, long time. C/C++ people are different: while it's true that many of them started with proprietary compilers and proprietary tools they embraced free replacement (GCC) wholeheartedly - but Java people never actually accepted free Java"

OK, sorry, forget about all the above. Clearly you are either a complete lunatic, or you are 12 years old.

Sorry but you do not know what you are talking about.

"I hear this from Java people a lot. But somehow proof never materializes. If Java is "everywhere" then it should be easy to point on the concrete examples, right. Where are they? "

OK, first of all, if you write "Java people" one more time, I ask LWN to help find you and I sue you for racial discrimination. Second, here are *a few* examples (listen script kiddie, you have to realize that I spend a huge amount of money just spending time to reply to you, so please, stop being an absolute idiot and listen OK? You did not listen to mommy, you did not listen to daddy, you did not listen to your teachers, for ONCE IN YOUR LIFE stop thinking you are smarter than the entire world. This IS NOT TRUE. Hard to accept, but once you do, you will realize that your relationship with your fellow human beings improve a lot)

The most used alternative to MS office
http://www.openoffice.org/

The most used software in functional network biology
http://www.cytoscape.org/

The most used software in system biology
http://www.celldesigner.org/

A *few* others (a few among hundreds, but the purpose is just an illustration OK? )
http://www.biouml.org/
http://www.biotapestry.org/
http://www.pathwayeditor.org/
http://www.async.ece.utah.edu/iBioSim/
http://physiome.org/jsim/
http://www.ebi.ac.uk/compneur-srv/SBMLeditor.html
http://smartcell.crg.es/
http://vanted.ipk-gatersleben.de

That is only one subfield of life sciences. Now I got bored. I let you explore the other fields of life sciences, and the other type of sciences (use Google :-) ) You will discover several thousands end-user applications written in Java, used by several hundreds thousands users. I will not venture millions, because I do not know.

"But these are small niches: Enterprise, HPC, may be some science. Where price of computer is not important because it's attached to some uber-expensive piece. But where people actually care about efficiency... Java is quite scarce."

Ah ah ah. So, people in science and HPC do not care about efficiency right? Do-you just read what you write?

And Enterprise, HPC and science are "small" niches. OK, fine, let us in our niches. Jeez.

Well, if you are so sure it's not just enterprise then it's easy to prove, right

Posted Sep 9, 2010 12:25 UTC (Thu) by wookey (guest, #5501) [Link]

lenov, it sounds like maybe you are a FOSS person and a java person, but really Khim is quite right that for a long time the two groups were largely separated by the Java licence. I know I spent years not using it because I couldn't, even though this was quite inconvenient (one very interesting/relevant app was written in Java).

Open JDK has enormously improved the situation, (so I have now packaged and used the app in question, and in fact it now also works with the gcj stuff too).

But railing at Khim because you don't like what he is saying doesn't really help your case. Java is still peripheral in Free Software, although apparently it is popular in science. I have seen it in a couple of control apps (DIYzoning, Mango - which were great but I entirely failed to get to build and run on ARM last time I tried, so I went elsewhere)

I guess you are right that a lot of 'special purpose' software is written in Java, but very little core stuff. Most of those things are 'niches', but it's true that if you add all the niches together (biology, physics, building design, cave surveying, etc, etc) the total perhaps cannot really be described as 'niche' overall. I don't know how to do that calculation - there is so much software in the world now I'm not sure anyone is counting it anymore :-). From where I'm standing more and more of it is being done in Python instead these days, but I can only see into a few niches.

Well, if you are so sure it's not just enterprise then it's easy to prove, right

Posted Aug 31, 2010 16:55 UTC (Tue) by Trelane (guest, #56877) [Link]

Java is too heavy for most users. Where you have power to spare it's not as important - and there Java is popular. But these are small niches: Enterprise, HPC, may be some science

In my experience, very little actual HPC is done with Java. Generally, it's C, C++, and FORTRAN, assisted by OpenMP, MPI, various linear algebra packages, and CUDA.

That said, I'm not at all opposed to it in some places, e.g. cross-platform GUI to do scientific visualization. It's also used in some monitoring applications, iirc. Generally, in HPC, you're trying to squeeze performance from every cycle you can; you don't want to waste it if you possibly can avoid it. HPC doesn't have the luxury of throwing away CPU as you indicate, because that would raise the power and cooling requirements which are already stretched, and decrease the FLOPS. I've seen it shown that Java floating-point isn't any slower than C or C++ floating-point (likely true depending on compiler choice and flags; you can get pretty big changes depending on your compiler and flags) but to my knowledge it's never really caught on so it keeps on not catching on (rather like FORTRAN 90 or 95 not catching on despite how hard FORTRAN 77 sucks). Also, the (in?)availability of mathematical packages (they're there, but relatively unknown and untested and thus untrusted) for it also hampers.

It could also be bigger in areas I don't have experience in (I'm a physicist, although my HPC experience comes primarily through workshops at our university's supercomputing center (which isn't a small one), so not specifically physics. I've not attended e.g. the Supercomputing Conferences, though, so it's possible I've just not been exposed to a wide enough HPC setting.

Google bails out of JavaOne

Posted Aug 31, 2010 10:22 UTC (Tue) by pboddie (guest, #50784) [Link] (3 responses)

This is ridiculous. I have seen developers assembling entire applications in a day with Java + IntelliJ IDEA and Eclipse.

Well, that's great. Maybe things have moved on since I last looked at what was supposed to be the state of the art. I could ask you to distinguish between "assembling" and "developing" (and inform us about the kind of applications in question) but...

I don't understand this thread. LWN is usually full of knowledgeable, reasonably argumentative. But this thread looks like some kind of religious war against Java by ignorant script kiddies playing the geeks.

Is this your characterisation of me or are you just waving the finger generally? I started using Java in 1995 and it paid my wages for quite some time, but just because I don't buy into the whole "IDE exoskeleton" movement doesn't make me or anyone else with the same perspective "script kiddies".

Google bails out of JavaOne

Posted Aug 31, 2010 16:38 UTC (Tue) by lenov (guest, #15428) [Link] (2 responses)

"I started using Java in 1995 and it paid my wages for quite some time"

Ah ... Maybe we have something here. When did-you stop using Java? Java in 1995 was ... a project. I am ready to agree that anything until and including Java 1.2 was very slow, clunky and hardly usable.

Google bails out of JavaOne

Posted Aug 31, 2010 17:31 UTC (Tue) by pboddie (guest, #50784) [Link] (1 responses)

Maybe we have something here. When did-you stop using Java?

Is this the leading question where in response to my answer you exclaim, "Ah! You're completely out of touch!" I haven't been involved in developing entire systems in Java for a few years - I guess Java 1.6 may have been round the corner but not in production - but I am currently exposed to systems written in Java as a developer.

I am ready to agree that anything until and including Java 1.2 was very slow, clunky and hardly usable.

I'll admit that I've kept Java at arm's length for a while, but upon firing up NetBeans to enhance something recently, I was quite shocked to see how the core Java APIs are still a complete mess, even now, despite lots of opportunities to clean them up via the Java Community Process. What's also shocking (although hardly "news") is how many things which were new in the anticipated Java 1.2 (or "Java 2" if you're in marketing) are mostly documented by the screams of those waiting for bugs to be fixed or even any sign of improvement, most notably in the Swing stuff. I ended up reading a lot of bug reports, which is something no IDE will help you with.

I wouldn't recommend a Python 3 strategy for Java, but there's the lingering impression of "Something must be done!" and nothing actually being done. Whether you like the language or not, the initial deluge of opportunities and "stuff you can suddenly do more easily", mostly attached to the core APIs but also to things like the concurrency features, has given way to a increasing mass of legacy (that is, stuff the designers now regret) and overdue functionality that isn't as convincing despite the considerable performance improvements delivered over the years.

I'll disagree with you about Java before 1.2: although certain things were less powerful than competing solutions, it had a certain elegance if you were coming from a systems programming language, and it certainly had its appropriate uses as well as its inappropriate ones.

Google bails out of JavaOne

Posted Sep 1, 2010 2:33 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

"I'll admit that I've kept Java at arm's length for a while, but upon firing up NetBeans to enhance something recently, I was quite shocked to see how the core Java APIs are still a complete mess, even now, despite lots of opportunities to clean them up via the Java Community Process."

Ah, you're using NetBeans. That explains it...

Google bails out of JavaOne

Posted Aug 30, 2010 16:27 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (7 responses)

>It's possible that I mean something else when I refer to "incremental development": that you start out with a vague idea of what you want and then refine it, but you aren't forced into spelling out a rigid type hierarchy if you don't want to.

That's exactly what I'm talking about. You don't need to commit yourself to something rigid. Just write something and then refactor it, I usually do it this way.

>Sure, refactoring is helpful when you have to overhaul that rigid type hierarchy, and I've often wanted to improve the refactoring possibilities in Python, but then again I can get pretty far with a class/function/method search.

Most of my code doesn't even use inheritance/interfaces. And most of my refactorings are related to code itself, not to data types.

May be this is an explanation?

Posted Aug 30, 2010 23:30 UTC (Mon) by khim (subscriber, #9252) [Link] (2 responses)

That's exactly what I'm talking about. You don't need to commit yourself to something rigid. Just write something and then refactor it, I usually do it this way.

Well... if it's typical for Java programmer then it's good explanation for why Java must be killed ASAP. Because nothing good can come from this approach: if you don't think about rigid structure but leave some gaps here and there then it's no wonder that the end result is bloated resource hog. If you have ten layers (not all that strange for Java from what I'm seeing) and each layer adds 10% slowdown (as price for flexibility) then your creation wastes 60% of power, if there are 20 layers (rare, but I've seen such Java projects) and slowdown is 20% (still does not look all that scary, right?) then 97% of computer power is wasted in "flexibility".

It's true that some flexibility is good, but remember that every time you are leaving spacing between components "for future extensions" you are wasting resources - and these effects tend to grow over time.

Most of my code doesn't even use inheritance/interfaces. And most of my refactorings are related to code itself, not to data types.

If you don't change data types then why do you need to move the code around? What benefit do you expect to get from such refactoring?

May be this is an explanation?

Posted Aug 31, 2010 11:08 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

>Well... if it's typical for Java programmer then it's good explanation for why Java must be killed ASAP.

Well... if it's typical for non-Java programmers then it's good explanation for why they must be killed ASAP.

>Because nothing good can come from this approach: if you don't think about rigid structure but leave some gaps here and there then it's no wonder that the end result is bloated resource hog.

Be more specific.

>If you have ten layers (not all that strange for Java from what I'm seeing) and each layer adds 10% slowdown (as price for flexibility) then your creation wastes 60% of power, if there are 20 layers (rare, but I've seen such Java projects) and slowdown is 20% (still does not look all that scary, right?) then 97% of computer power is wasted in "flexibility".

Nope. I don't have any unnecessary 'layers' in my software. Mostly because I don't NEED to create them before I really _need_ them. And then I need them - I use refactorings to introduce required abstractions.

May be this is an explanation?

Posted Aug 31, 2010 13:54 UTC (Tue) by alankila (guest, #47141) [Link]

The real reason why java code seems to have so many layers follows from the fact that method call is the only means of abstraction in Java, so every thing that you want to do ends up encoded as a method call on some object. If the task has many steps, it will have many method calls.

However, simultaneously, Java seems to make it possible to freely call "virtual" methods in code without having to pay for it in form of significant slowdown because the JIT can often work it out and remove the indirection imposed by the myriad of layers.

This is one of my favorite things with Java, actually, because it makes it possible to write the code in a logical way yet have it execute quickly.

Google bails out of JavaOne

Posted Aug 31, 2010 10:29 UTC (Tue) by pboddie (guest, #50784) [Link] (3 responses)

Most of my code doesn't even use inheritance/interfaces. And most of my refactorings are related to code itself, not to data types.

The notion of interfaces is fundamental to the analysis and optimisation of Java programs, so when you write the first sentence above, I can only ask this: "Are you sure?"

Google bails out of JavaOne

Posted Aug 31, 2010 11:09 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

>The notion of interfaces is fundamental to the analysis and optimisation of Java programs, so when you write the first sentence above, I can only ask this: "Are you sure?"

Nope. Interfaces are just a way to create polymorphic behavior. They are certainly not 'fundamental' for optimization.

I prefer to use concrete classes and/or static helper methods instead of heaps of 'design patterns'. And when I need to introduce polymorphic behavior (which is not all that often) I just refactor required dependencies into interfaces.

Abstract classes are a pure evil, btw.

Google bails out of JavaOne

Posted Aug 31, 2010 12:21 UTC (Tue) by pboddie (guest, #50784) [Link] (1 responses)

Nope.

Nope, you're not sure that you don't use inheritance or interfaces? Well, you might not define inheritance or interfaces in your own code, but it's all going on in the rest of the system.

Or nope, you dispute that the presence of interfaces is what makes the generation of optimised code for Java easier than for, say, dynamic languages? Well, given that declarations in Java refer in their most general form to interfaces, I'd say that they offer more easily taken opportunities for efficient method dispatch - stuff that you have to work harder to deduce in dynamic languages.

Quite how my "class/function/method search" is undermined by a refusal to use inheritance or interfaces remains unclear. You might argue that my search won't find the right method because "it's a different one that uses the same name, and you can't tell that in Python", but if I'm coding Python like you appear to code Java, it seems less likely to be a problem (I won't have lots of classes with lots of methods with similar names), and if I'm coding Python in a more natural fashion, it only brings us right back to the mechanisms which do let you tell the difference between methods having the same name in, say, Java. Which are classes, interfaces and inheritance.

Google bails out of JavaOne

Posted Aug 31, 2010 16:38 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

>Nope, you're not sure that you don't use inheritance or interfaces? Well, you might not define inheritance or interfaces in your own code, but it's all going on in the rest of the system.

I do not _overuse_ them. They certainly are necessary. However, they certainly are NOT necessary everywhere a simple specific class can be used.

Google bails out of JavaOne

Posted Aug 28, 2010 16:29 UTC (Sat) by bronson (subscriber, #4806) [Link] (3 responses)

Because Java is statically typed, its direct replacement must be statically typed. It's that simple.

Remember that Java is usually picked by middle managers trying to reduce their risk. If one chooses Haskell and the project implodes, it's his fault and he'll have to run in circles trying to justify it. If he chooses Java and the project implodes the there's hundreds things to blame it on but he won't have to defend the language.

The world is far from perfect. :)

Google bails out of JavaOne

Posted Aug 28, 2010 17:10 UTC (Sat) by trusmis (guest, #47355) [Link] (2 responses)

What about C++?

Google bails out of JavaOne

Posted Aug 28, 2010 18:06 UTC (Sat) by MisterIO (guest, #36192) [Link] (1 responses)

Horrible syntax, horrendous error messages.

Google bails out of JavaOne

Posted Sep 1, 2010 22:57 UTC (Wed) by daniel (guest, #3181) [Link]

And no garbage collection. Still, I prefer to write in C++ over Java, I put in a little more work and the result is (usually) not a sluggish memory pig.

Google bails out of JavaOne

Posted Aug 29, 2010 3:46 UTC (Sun) by trusmis (guest, #47355) [Link]

Vala
http://live.gnome.org/Vala/Tutorial

Google bails out of JavaOne

Posted Aug 28, 2010 5:25 UTC (Sat) by drag (guest, #31333) [Link] (26 responses)

> there are so many other languages with better OO implementations than java that are more cross platform, dont have stupid memory handling and with huge libraries (or 'classes' if you like that term) of functions to draw upon - why waste any more time on java?

* Because it is what they are using already.

* Because a shitload of people are familiar with Java and will continue to use it heavily absolutely regardless of what Google or Oracle does.

* Because abandoning Java language would abandon everything that Android is and Android has achieved so far.

* Because all programming languages suck even if they suck differently so there would probably be no net gain in switching to Java anyways.

* Because the 'quality of OO implementation' is really incredibly irrelevant to any sort of software being developed in the real world. Java's is certainly sufficient.

* Because any program that has a sufficiently modern facilities is going to have just as much threat from software patents as Java (or C#/Mono/.NET for that matter). Running away from patents are not going to help you any in the long run.

etc etc etc etc.

FUD, FUD, FUD...

Posted Aug 28, 2010 12:14 UTC (Sat) by khim (subscriber, #9252) [Link] (25 responses)

* Because it is what they are using already.

How many mobile developers knew Objective C three years ago? How many do now?

* Because a shitload of people are familiar with Java and will continue to use it heavily absolutely regardless of what Google or Oracle does.

It's their problem. Lots of people are familiar with Cobol - that does not mean FOSS community should spend resources to support it.

* Because abandoning Java language would abandon everything that Android is and Android has achieved so far.

Not really. Core Android libraries are not Java, they are C++ (linux kernel, SQLite, SKIA, etc). Java is only used to tie everything together. Switch to other glue language may be painful, but if language is good it can be done. Perhaps Google Go? In any case: you are correct, that's up to OHA: if they decide that Java is not a way to go developers will go with them, if they decide that it's not worth it, then that's that.

* Because all programming languages suck even if they suck differently so there would probably be no net gain in switching to Java anyways.

Depends on the language involved, but the fact that it'll mostly remove Oracle from the equation is good enough incentive.

* Because the 'quality of OO implementation' is really incredibly irrelevant to any sort of software being developed in the real world. Java's is certainly sufficient.

It was sufficient month ago, but we don't know anything about year from now. It's always good to have "Plan B" - even if you'll not actually use it.

* Because any program that has a sufficiently modern facilities is going to have just as much threat from software patents as Java (or C#/Mono/.NET for that matter).

C#/Mono/.NET are right out. OHA should look on something like OCaml or Google Go.

* Running away from patents are not going to help you any in the long run.

If run alone - no, it does not help, if you organize a stampede - it does. I don't know if Google can organize a stampede WRT to Java, time will tell.

FUD, FUD, FUD...

Posted Aug 28, 2010 15:33 UTC (Sat) by drag (guest, #31333) [Link] (24 responses)

> How many mobile developers knew Objective C three years ago? How many do now?

A tiny group of people compared to Java in both cases.

> Not really. Core Android libraries are not Java, they are C++ (linux kernel, SQLite, SKIA, etc). Java is only used to tie everything together. Switch to other glue language may be painful, but if language is good it can be done. Perhaps Google Go? In any case: you are correct, that's up to OHA: if they decide that Java is not a way to go developers will go with them, if they decide that it's not worth it, then that's that.

The applications that run on those libraries are the important part, not the libraries themselves. It's the same thing for all OSes... the libraries and the operating system are there just to run the software.

Maybe this is the big thing that most Linux folks miss? The applications are important and the OS is only as important as the applications that depend on it. Maybe using the term 'linux' for everything is part of the problem.

In terms of what people need on their computers: The kernel, if it's doing it's job correctly, is the software users/developers have to care about the least. The libraries and such are more important then the kernel, but they are still much less important then the stuff that runs on the libraries and such.

If you can abandon Java while maintaining 100% of compatibility with existing software and do not require developers to use new SDKs and such then what your saying would make sense.... but obviously that is impossible.

> If run alone - no, it does not help, if you organize a stampede - it does. I don't know if Google can organize a stampede WRT to Java, time will tell.

No, your missing the point. Even if your not using Java or .NET or anything else that already exists you can just as easily violate Java's or .NET's patents. Using something based on LLVM or Parrot or whatever can violate their patents just as much as using OpenJDK. It depends on what exactly the patents cover, but there are patents everywhere and if Microsoft, Oracle, and friends are willing to sue you over Java they have the power to sue you over anything.

Wow... Interesting news...

Posted Aug 28, 2010 17:30 UTC (Sat) by khim (subscriber, #9252) [Link] (23 responses)

> How many mobile developers knew Objective C three years ago? How many do now?

A tiny group of people compared to Java in both cases.

Wow. Are you sure about that? GetJar contains about about the same number of applications as Apple's App Store. Do you want to imply that "tiny group of people" was able to write the same number of applications in 1/4 of time? If then then it's really time to ditch Java.

Or may be you are talking about Enterprise Java? These people are irrelevant to discussion: you can not use most Enterprise Java tools and knowledge on mobile: Java ME is stuck is stone age and JavaFX is obscurity not worth talking about.

The applications that run on those libraries are the important part, not the libraries themselves. It's the same thing for all OSes... the libraries and the operating system are there just to run the software.

But this is not the end of pyramid: the software itself is designed to satisfy needs of users. If new platform is in hands of millions of users then the developers will come - and it'll not matter if they can use existing language or not. Take a look on this list, for example... need I remind you that platform is not even year old and uses yet-another-incompatible-subset-of-C++?

If you can abandon Java while maintaining 100% of compatibility with existing software and do not require developers to use new SDKs and such then what your saying would make sense.... but obviously that is impossible.

Of course, but then you insistence on "no new SDKs and such" only makes sense for the PC. Mobile is not PC. On PC you can just put JDK in the installation package and deliver it as package (that's why Java survived after Microsoft stopped distributing it). It does not really work in mobile world: if you want to sell Java app and the phone of your potential customer does not support Java... well, your only choice is to go, download new, incompatible SDK and start cranking anew...

Using something based on LLVM or Parrot or whatever can violate their patents just as much as using OpenJDK.

Android never used OpenJDK and never tried to claim they are using OpenJDK.

It depends on what exactly the patents cover, but there are patents everywhere and if Microsoft, Oracle, and friends are willing to sue you over Java they have the power to sue you over anything.

Sure, every piece of software can be attacked with patents, but it's much, much easier for partial clone. Again: take a look on H.264 vs WebM. Heck: take a look on MP3 vs Vorbis! Talks about patent attacks on Vorbis are many years long yet noone actually tried to actually attack it... Why? It's hard money: you must prove that something which implement unrelated specification still infringes on your patent. Compare with Microsoft's FAT cases where independent software implemented Microsoft's specification. No, abandonment of Java will not remove patents threats entirely, but it'll reduce it many times...

And it's not as hard as you imply: there are already talks about bringing multiple languages (like PHP or Python) to Android. Java will become less and less important to Android in the future anyway - perhaps that's why Oracle decided to sue now, rather then later...

Wow... Interesting news...

Posted Aug 28, 2010 17:57 UTC (Sat) by trusmis (guest, #47355) [Link] (14 responses)

You can have a bunch of languages on Android but you want something fast (if only because you want to save battery), so your choices are:

C, C++ (faster than Java) (too complex??)
Java
Skala (but depends on jvm anyway)
Lua (Luajit is damn fast, dont know the language, can't point a disadvantage)
Haskell (too weird)

Anything other than this, already too slow or noone really uses it.

Wow... Interesting news...

Posted Aug 28, 2010 19:37 UTC (Sat) by dlang (guest, #313) [Link] (12 responses)

the speed of the code has relatively little to do with how much battery is used because most of the battery is still used while the cpu is relatively idle, but the screen, radio, etc are powered up because the user is looking/listening to something.

Wow... Interesting news...

Posted Aug 29, 2010 1:19 UTC (Sun) by trusmis (guest, #47355) [Link] (11 responses)

Surely you are right. It is not about battery but about responsiveness.
Every action of the user will need much more processing.

I wonder how happy would be developers porting from iphone to android and discovering their app or game is painfully slow
And how happy hardware developers to discover they need a more faster and more expensive cpu to keep up with competing offerings...

It's easy to build fast Android app

Posted Aug 29, 2010 7:51 UTC (Sun) by khim (subscriber, #9252) [Link] (10 responses)

Actually it's not that hard to write fast and responsive Android app. You just must use manual memory allocation (don't rely on GC, place everything in byte[] array and use your own primitive malloc/free... may be few such arrays) and C/C++ where pissible (via NDK). The end result works relatively well, but it's not really Java (Enterprise Java developers will scream in horror because their beloved technologies are perverted and thrown out of the window) and it can be easily ported to Google Go or any other language if OHA will decide to switch gears in the future.

Java on mobile was bad idea 10 years ago and it's bad idea now. Sadly marketing and PR trump technical aspects... but that means that good marketing and PR can kill Java on mobile quite fast too...

It's easy to build fast Android app

Posted Aug 29, 2010 22:42 UTC (Sun) by ibukanov (subscriber, #3942) [Link] (9 responses)

> Java on mobile was bad idea 10 years ago and it's bad idea now.

It was not. 10 years ago it was possible to write a full-featured (JavaScript and CSS2 was supported) and responsive browser in Java that worked well for many embedded devices like set-top boxes and that would be stable enough to run for weeks without crashes or memory leaks. And that was using 1.1 JDK-compatible VMs. An Android phone has 10 times faster CPU and 10 times more memory with better engineered VM. So if an applications has issues, blame the application developers, not the technology.

You've just proven me wrong...

Posted Aug 30, 2010 5:53 UTC (Mon) by khim (subscriber, #9252) [Link] (8 responses)

10 years ago it was possible to write a full-featured (JavaScript and CSS2 was supported) and responsive browser in Java that worked well for many embedded devices like set-top boxes and that would be stable enough to run for weeks without crashes or memory leaks.

You mean HotJava? The fact that we are not seeing Java Browsers today even on desktop speaking for itself: when HotJava was abandoned it become obvious to all sane people (well, for anyone who still believed that Corel was to blame for "CorelOffice for Java" failure and not Java) that Java failed to deliver on it's promise. It was atrocious browser back then and it's practically unusable now. It was slow and laggy as hell - even compared to Netscape. And it's pointless to compare it with today's browsers (which are even slower and require more resources) since they need to support a lot of things HitJava never had. But I'm afraid that if you actually create the heavy JavaScript page without new technologies it'll show that even today's browsers are small and nimble compared to the HotJava behemoth.

An Android phone has 10 times faster CPU and 10 times more memory with better engineered VM.

VM is not a big problem. GC is. Or rather combination of standard library which creates objects like rabbits and poor GC. VM is also a problem, but smaller one.

So if an applications has issues, blame the application developers, not the technology.

Sorry, but no. You know the saying: one is an accident, two is a trend, three is a problem. There easily seen correlation between language and performance: C/C++ programs are small and fast, C#/Java programs are bloated and slow. It's not that Java makes it impossible to write small and nimble programs. It just makes it hard. And on mobile lost cycles means shorter worktime from battery - it's as simple as that. Even if today's phone have power to spare you don't want to use it pointlessly - and this is exactly what Java programs are doing.

I've outlined above how you can write the programs which work fast and use limited memory. It's possible: treat a Java as obstacle between your and hardware and you'll succeed. But... if you must treat Java as obstacle and not helper then why it's even there to hamper you?

You've just proven me wrong...

Posted Aug 30, 2010 7:47 UTC (Mon) by ibukanov (subscriber, #3942) [Link] (2 responses)

> You mean HotJava?

No. HotJava was a useless resource hog that Sun AFAIK could not managed update to support CSS even it was written with all those design patterns Sun advocated to use. Eventually Sun gave up assuming that for serious browsing one needs native code.

That was wrong. There were commercial browsers that showed that Java was up to the task. Unfortunately after dot.com burst and few management mistakes they were also almost abandoned. One of them, IceBrowser, still exists today for a niche marked. The key for their lightweightness and speed was to avoid unnecessary object creation while taking full advantage of the garbage collector to simplify interaction between components.

> Or rather combination of standard library which creates objects like rabbits and poor GC.

I agree only on the bad standard library part. That is the real problem and the biggest obstacle IMO for Java on devices. If one avoids putting too much pressure on the GC and schedules that when the user is not interacting with the application, then it works nicely making fast and responsive programs.

> It's not that Java makes it impossible to write small and nimble programs. It just makes it hard.

It is not that hard. One just need to avoid few design patterns and some system libraries. Too bad author of all those Java books and courses teach precisely wrong leading to code that even on server can strain the VM.

> It's possible: treat a Java as obstacle between your and hardware and you'll succeed. But... if you must treat Java as obstacle and not helper then why it's even there to hamper you?

Because in Java one can modular and robust code (GC and memory protection) that can perform close to C/C++ code (really optimized VMs).

Well, these are weak reasons IMO...

Posted Aug 30, 2010 23:49 UTC (Mon) by khim (subscriber, #9252) [Link] (1 responses)

Because in Java one can modular and robust code (GC and memory protection) that can perform close to C/C++ code (really optimized VMs).

You can write modular and robust code in many languages (GC is not Java-exclusive and I'm not convinced it's even good idea for mobile), Java memory protection is a joke (and Android does not use it anyway), so what's left? Effective IDEs? This is important advantage, but is it important enough to cope with all disadvantages? We'll see how it goes soon, I suppose.

Well, these are weak reasons IMO...

Posted Aug 31, 2010 11:57 UTC (Tue) by ibukanov (subscriber, #3942) [Link]

> You can write modular and robust code in many languages

Yes, but that code in Java would also be fast. This is due to highly optimized and mature VMs. Of cause, one of the reasons for the optimizations is the need to deal with badly written Java code that Java standard library encourages, but if one know how to deal with that, then the result would be a fast, lightweight and responsive application.

> Java memory protection is a joke

Could clarify what do you mean by "memory protection"? Do you imply an ability to run multiple applications in single VM? If so, I agree with that, but only in part that in such configuration it is impossible to prevent denial-of-service.

> Android does not use it anyway

On Linux processes are cheap so Android can take advantage of all process isolation features that OS provides. Still I am glad that without native code one cannot write for Android something like

while (1) {
malloc(1 << 26);
fork();
}

that Linux deals pretty badly with.

You've just proven me wrong...

Posted Aug 30, 2010 19:13 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

There is a reasonably-compatible pure Java browser: http://www.icesoft.com/products/icebrowser.html

It worked quite well back in 2003 when we used it for embedded HTML rendering. It supported JS and CSS way back then. Unfortunately, it also costs an arm and a leg. We payed around $500000 for it (I wish I were joking).

So technically it was possible to implement a fast browser in Java.

Well, I can not verify it, but ok...

Posted Aug 30, 2010 23:44 UTC (Mon) by khim (subscriber, #9252) [Link] (3 responses)

Well, I'll assume you are correct and there was good Java Browser (was because as you can see it'll be dead in a few months). This still does not explain why there are four widely used independently written browser engines in C++ today and zero written in Java left. If Java is oh, so much easier then why only one company ever managed to write fast and light relatively popular Java engine, why Sun was never able to do it (and they are inventors of Java, they had the best Java developers at the time!), and why even that last company now abandoned it.

I can understand why there are no Haskell browsers: it's big task and there are not a lot of Haskell developers. But from what I'm seeing there are more Java developers then C++ developers... and everyone says they are oh, so uber-productive... yet we see no browser, no word processor, no spreadsheet. It's possible that they can not produce simple desktop programs and their destiny is endless "enterprise" monsters, but then... how it's relevant to mobile? It's pretty much opposite from enterprise development!

I'm still not sure I can explain why many (most?) Java programmers produce bloated resource hogs, but this is the fact. If Java is not to blame then what is? They can not all be idiots!

Well, I can not verify it, but ok...

Posted Aug 31, 2010 11:25 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

>Well, I'll assume you are correct and there was good Java Browser (was because as you can see it'll be dead in a few months). This still does not explain why there are four widely used independently written browser engines in C++ today and zero written in Java left.

Several answers:
1) No good GUI framework. SWING (still) has a lot of problems, with performance and features, in 2000-s it was even worse.
2) No _need_ for a new browser.
3) Resources. Java is reasonably fast, but it requires a lot of RAM.
4) It's still a huge task, even in Java.

>If Java is oh, so much easier then why only one company ever managed to write fast and light relatively popular Java engine, why Sun was never able to do it (and they are inventors of Java, they had the best Java developers at the time!), and why even that last company now abandoned it.

Heh. Sun's inability to find its ass with two hands in Java development is legendary. They produce a very good quality JVM, but for a long time they couldn't produce anything of quality _in_ Java. EJB2 was legendary for the fact that it spawned dozens of OpenSource frameworks to replace it.

>I'm still not sure I can explain why many (most?) Java programmers produce bloated resource hogs, but this is the fact. If Java is not to blame then what is? They can not all be idiots!

Right now, I'm writing Python code. In PyCharm IDE which is based on IDEA which is written in Java. It does eat quite a lot of RAM, however it's also the fastest and most powerful Python environment I've ever seen.

While WingIDE in Python is STILL slow as hell and has much less capable autocomplete/refactorings.

Well, I can not verify it, but ok...

Posted Aug 31, 2010 12:25 UTC (Tue) by ibukanov (subscriber, #3942) [Link] (1 responses)

> This still does not explain why there are four widely used independently written browser engines in C++ today and zero written in Java left.

Strictly speaking there are 3 rendering engines, Mozilla, WebKit and Opera and all of them has started prior 2000. At that moment there were two reasonably performing Java browsers, something called like Espeal and IceBrowser in addition the HotJava joke. But they were not able to survive the dotcom burst (perhaps due to their proprietary nature, perhaps for other reasons).

So the real question is why nobody was able to create a new browser engine in any language during the last 10 years outside some niche or research projects.

> why Sun was never able to do it (and they are inventors of Java, they had the best Java developers at the time!)

You must be joking. I agree 100% with the comment above that Java programmers at Sun are among the worst ones. As often the case the inventor of a tool is its least efficient user.

Well, I can not verify it, but ok...

Posted Aug 31, 2010 12:30 UTC (Tue) by ibukanov (subscriber, #3942) [Link]

> Mozilla, WebKit and Opera

Sorry, I forgot MSIE, so indeed, 4 engines in total, but still nothing new for the last 10 years.

Wow... Interesting news...

Posted Sep 2, 2010 23:33 UTC (Thu) by juanjux (guest, #11652) [Link]

Two more languages I would consider:

1. Python with the Unladen Swallow JIT (already being used by Google on Youtube). Pro: lots of programmers, a lot more productive than Java. Cons: memory usage. Speed? (I dont know how un.sw. compares to Dalvnik)

2. D 2.0: Pros: Fast, practical, powerful syntax and very nice productivity. Cons: not many programmers or libraries.

Wow... Interesting news...

Posted Aug 28, 2010 22:08 UTC (Sat) by ibukanov (subscriber, #3942) [Link]

> If new platform is in hands of millions of users then the developers will come - and it'll not matter if they can use existing language or not.

I second that. The language issue is greatly overrated.

I have lived through and observed a language switch in few projects. The switches were dictated by the deficiencies of tools (Pascal -> C++), slowness of the implementation (C -> Fortran) or customer requirements (C++ -> Forth). In all cases the involved people adapted relatively quickly and within a month or two the became efficient within the new language.

A more recent example would be an experience of a friend with extensive Java background. He had to port his application to iPhone from Android. He said that compared with Android programming for iPhone really sucked and a new language was the least of his worries. The awkwardness of libraries and tools were much bigger issues.

Wow... Interesting news...

Posted Aug 30, 2010 4:26 UTC (Mon) by vonbrand (guest, #4458) [Link]

Please don't compare apples and oranges. (V)FAT was specifically choosen for compatibility (and there was not much of a choice of doing it the exact same way). Vorbis was carefully designed to minimize its potential patent liabilities.

Wow... Interesting news...

Posted Aug 31, 2010 13:46 UTC (Tue) by nhippi (subscriber, #34640) [Link] (5 responses)

> If new platform is in hands of millions of users then the developers will come - and it'll not matter if they can use existing language or not.

Not completely true. Symbian is still selling every day more units (300k) than android (200k). yet, it completely fails to capture developer attention. mostly due to using too exotic variant of c++.

j2me has by far the largest amount of supported phones, yet it is also starting to lag behind android. This time the reason is having too many minor incompatibilities between j2me phones. A problem that will also hit Android hard soon.

Wow... Interesting news...

Posted Aug 31, 2010 14:11 UTC (Tue) by foom (subscriber, #14868) [Link] (4 responses)

> Not completely true. Symbian is still selling every day more units (300k) than android (200k). yet, it completely fails to capture developer attention. mostly due to using too exotic variant of c++.

I doubt that's the problem.

It never even occurred to me [note: I live in the USA] until recent conversations here that it might make sense to develop an app for Symbian. In order of perceived importance: iPhone, Android, Blackberry; the end. I'll note that I've not seen any requests from users for a Symbian app either, but have seen requests for Android and Blackberry.

When I think of Nokia, I think of "feature phones" and the N800/etc maemo tables. I suspect the lack of developer attention to Symbian is foremost a failure in marketing, not in technology. The development environment might also suck (or maybe it doesn't, I have no idea), but it doesn't seem like the main problem.

Wow... Interesting news...

Posted Sep 1, 2010 1:06 UTC (Wed) by klbrun (subscriber, #45083) [Link] (3 responses)

Developing for Symbian IS a pain, largely because it started out as a proprietary system (using an exotic variant of c++); only recently has Symbian become open source, and it is definitely not used for "smart phones". Nokia's smart phone OS was Maemo, and will be Meego.

The US has a unique cell phone system that pretty much rules out Nokia phones. For a while it looked like WiMax would compensate. There are good reasons why Google decided to accomodate the carriers when it introduced Android.

Wow... Interesting news...

Posted Sep 1, 2010 1:53 UTC (Wed) by foom (subscriber, #14868) [Link] (2 responses)

> Developing for Symbian IS a pain, largely because it started out as a proprietary system (using an exotic variant of c++); only recently has Symbian become open source,

Like the iPhone? Having an exotic variant of C++ and being proprietary doesn't seem to have hurt there...not to say developing for Symbian isn't a pain, but those aren't reasons.

> and it is definitely not used for "smart phones".

Reeaally? What do you call the N95, etc? Nokia certainly markets them as smart phones.

> Nokia's smart phone OS was Maemo, and will be Meego.

Maemo was an experiment on some internet tablets, for a long time. Yes, they've *now* (late last year) announced they're going to use Maemo/Meego on future smartphones...but to say that Symbian was never designed to be a smartphone OS seems a statement lacking in history.

> The US has a unique cell phone system that pretty much rules out Nokia phones

Er, *WHAT*? Nokia was a huge player in the US cell phone market for a long time. Basically until smartphones became popular... They probably still have a large slice of the cheap phone segment of the market.

Wow... Interesting news...

Posted Sep 1, 2010 2:43 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

>Like the iPhone? Having an exotic variant of C++ and being proprietary doesn't seem to have hurt there...not to say developing for Symbian isn't a pain, but those aren't reasons.

Ahh, there are several differences:
1) Apple zombies.
2) Symbian C++ is much much much less nicer than Objective-C/C++.
3) Apple zombies.

Wow... Interesting news...

Posted Sep 8, 2010 11:52 UTC (Wed) by mishad (guest, #69757) [Link]

4. iPhone owners being predominantly consumers with demonstrated disposable cash, rather than the more enterprise-biased owners of typical Symbian phones. Sell to the market with money to burn...

Google bails out of JavaOne

Posted Aug 28, 2010 11:41 UTC (Sat) by alankila (guest, #47141) [Link] (15 responses)

To someone who actually enjoys working with java, your words sound absolutely insane. It'll take a lot of effort to replace java, neither Perl nor Python are even contenders. Sheesh.

Liking Java

Posted Aug 28, 2010 16:12 UTC (Sat) by man_ls (guest, #15091) [Link] (14 responses)

If you haven't read Execution in the Kingdom of Nouns yet please do. Even if you love Java you will probably get a good laugh out of the "For the lack of a nail" poem, and there is a deep truth in it which can be summed up as: "Dude, not everything is an object". I used to love Java and still like it, but after a couple of years of Python hacking I feel a bit lazy using the Java language for anything really complex.

Liking Java

Posted Aug 28, 2010 16:43 UTC (Sat) by bronson (subscriber, #4806) [Link]

Good poem! And it went easy on Java -- it gave little attention to dependency injection, aspect-oriented programming, or cross-cutting concerns.

Liking Java

Posted Aug 28, 2010 17:34 UTC (Sat) by tjc (guest, #137) [Link] (4 responses)

Thanks for the link! "For the lack of a nail" articulates my weariness with Java.

Well, Android is a rebel, then...

Posted Aug 28, 2010 18:26 UTC (Sat) by khim (subscriber, #9252) [Link] (3 responses)

Actually programming under Android is slightly different: you don't need to create and destroy billions of noons. For example you can write the program which can run for a long time without creating new objects... as long as you can avoid standard java classes! Heck, you can draw the whole 3D scene on Android while creating less objects then printf("%6.2f", MyFloat) creates!

This tendency makes me kinda sad: it's quite obvious that Java is ill-suited to mobile, but it does not stop intelligent people from trying to push it there... why?

Well, Android is a rebel, then...

Posted Aug 28, 2010 21:33 UTC (Sat) by nicooo (guest, #69134) [Link] (2 responses)

For the same reason that everyone uses qwerty?

Rebels against the empire

Posted Aug 29, 2010 0:44 UTC (Sun) by man_ls (guest, #15091) [Link] (1 responses)

Actually, the supposed superiority of the (patented) Dvorak keyboard layout is based on a deeply flawed study -- and a subsequent stream of flawed literature. This case was (for me at least) an eye opener which I always keep in mind.

Rebels against the empire

Posted Aug 29, 2010 1:57 UTC (Sun) by nicooo (guest, #69134) [Link]

My point still stands, although now it's in Java's defense. =]

Specially since using a different language is a lot easier than using a different keyboard layout.

Liking Java

Posted Aug 29, 2010 10:14 UTC (Sun) by alankila (guest, #47141) [Link] (6 responses)

I'm aware of the stuff Yegge writes. This poem is a fine example of the kind of rampant overengineering that goes in Javaland, and I think the primary problem is the use of Java as a teaching language. It takes some time to realize what is worth modeling and what not, and inexperienced people do not yet understand but do everything in the heaviest possible way.

Secondly it may fundamentally take some time to understand how to use objects as a modeling tool. To put this back into original Perl/Python context, it's possible to program those languages pretty much just like they were java too, however nobody does. It's interesting to ponder why. Regardless, it is a rare Perl system that would strike me as especially well-designed, so please do not read that as an endorsement of Perl. (I have far less experience of Python to comment much about that.) Ultimately, I suspect it's all about the quality of programmers your language attracts.

Finally, I do not think Java even attempts to claim that all things are objects. It's more like this: there's a C-style expression language for computation which appears to have little notion of objects or methods, and is not extendable in any way at all. It goes so far that you can't do "5.toString()" because you'd be calling the method on a value type.

However, there is basically no way to extend java except by modeling everything as objects, so all larger system must be composed of objects because there is just no other practical way to do it, and objects support only method call and identity test, no other operations. (Which perhaps gives rise to Yegge's rant of nouns. It reads as if he would be perfectly happy if Java had first-class functions.)

Nonfunctional Java

Posted Aug 29, 2010 14:35 UTC (Sun) by man_ls (guest, #15091) [Link] (5 responses)

There is more to functional programming than having functions as first-class citizens which can be passed around; otherwise C++ (and even C) would be functional. What is missing are some constructs which make it easy to do the one thing that programming languages should do: avoid code repetition. The result is not only more compact than the procedural equivalent, but also much more malleable over time.

The most striking thing is that functional constructs are readily understandable to anyone with some programming background. Some Python examples:

Lambda function: pass an anonymous function which can then be used in another function. Example:
```
self.collect(lambda x: x < 3)
```
Generator: a function which yields a new value of a sequence every time it is invoked. Example:
```
def countfrom(n):
  while True:
    if complexcondition(n):
      yield n
    n += 1
```
List comprehension: operate on a list and return another list. Example:
```
list = [2*x for x in range(101) if x**2 > 3]
```

Doing the equivalent things in Java require a painstaking hierarchy of classes and interfaces which are never satisfying even to the advanced practitioner. Hence the over-abundance of classes and singletons, and in turn the invention of design patterns to make these constructs understandable. It can be done, but it's not going to be pretty.

Nonfunctional Java

Posted Aug 30, 2010 0:10 UTC (Mon) by alankila (guest, #47141) [Link] (4 responses)

Yes, yes. The java methods are agreeably more verbose, and do not look that functional. For instance:

interface IFunction {
boolean test(int x);
}

and using that as:

collect(new IFunction() { boolean test(int x) { return x < 3; } });

looks worse, thanks to the typing noise and the declaration of the anonymous inner class. Then again, self.collect() is not a core Python function, so I can just demand that the Java equivalent be defined to accept an IFunction, and call that fair. It wouldn't take a lot of compiler trickery to make this stuff look a lot nicer, though. *sigh* There has been a lot of fighting in javaland about how to best implement these things and whether they should get compiler help. Last time I looked, there still wasn't any agreement on anything.

This might be a good idea to mention lambdaj, which relies on runtime code generation to do its thing. It can provide jQuery-style forEach/map iteration and can treat collections of objects as if they were just a single object. All this fairly dynamic behavior is based on runtime class generation, I think.

Generators would have to be modeled as java Iterable, but demonstrating the equivalent would probably take even more lines and I can't remember the iterator contract off the top of my head because I've only dabbled with implementing them once or twice. I'd say it's somewhat matter of taste whether you have a "yield" or some nextElement() call given that all your state can be captured in the object representing the iteration rather than the local variable scope.

Finally, for list comprehension you'd have to bite the bullet and write something like this:

List<Integer> x = new ArrayList<Integer>();
for (int i = 0; i < 101; i ++)
if (i * i > 3)
x.add(2*i);

I guess the argument here is largely about how the weight of having to type and remember more weighs you down, right? I do think that the "painstaking hierarchy of classes and interfaces" for these particular examples falls in the realm of hyperbole, though. In fact, I'd guess that majority of world's programmers would rather stare my version of that particular comprehension than Python's. (Also, amusingly, you committed the newbie sin #1 and overrode the list builtin.)

Nonfunctional Java

Posted Aug 30, 2010 6:18 UTC (Mon) by man_ls (guest, #15091) [Link] (3 responses)

I guess the argument here is largely about how the weight of having to type and remember more weighs you down, right?

In fact it is about avoiding duplication while using the natural constructs of your language. E.g. at my job, if I write any of the Java code you propose and put in in production, nobody is going to understand it; writing maintainable code requires that you stick to "procedural" classes and methods. With Python nobody is going to look sideways at a functional construct.

I do think that the "painstaking hierarchy of classes and interfaces" for these particular examples falls in the realm of hyperbole, though.

In practice, function-like constructs as those you propose are often forbidden, forcing developers to construct the "painstaking hierarchy"; not to simulate functional programming, but to create the procedural equivalent.

Don't get me wrong; I've spent like 10 years writing (and reading) Java professionally and I have enjoyed it a lot, while I have only used Python for about 1.5 years privately. I used to hear about functional programming and sneer a little bit in my ignorance. At the same time I was often unhappy with so many hierarchies and design patterns. Python has opened doors which have made my code much tighter and more malleable, while being equally readable. Less plumbing and less duplication, and the structure is there for everyone to see just as before.

I don't know how Java can adopt functional programming or if it should even try. Generics and aspect programming have caused enough chaos already.

(Also, amusingly, you committed the newbie sin #1 and overrode the list builtin.)

Yeah, I do that. I know I shouldn't, and luckily vim shows it in cyan letting me know :)

The difference is not Java vs Python, it's "professionally" vs "privately".

Posted Aug 30, 2010 11:01 UTC (Mon) by khim (subscriber, #9252) [Link] (1 responses)

With Python nobody is going to look sideways at a functional construct.

Are you sure? Google's style guide says: "List Comprehensions: Okay to use for simple cases. Each portion must fit on one line: mapping expression, for clause, filter expression. Multiple for clauses or filter expressions are not permitted. Use loops instead when things get more complicated.", "Lambda Functions: Okay to use them for one-liners. If the code inside the lambda function is any longer than 6080 chars, it's probably better to define it as a regular (nested) function."

And it's one of the more liberal ones. A lot of companies just flat out forbid them.

Don't get me wrong; I've spent like 10 years writing (and reading) Java professionally and I have enjoyed it a lot, while I have only used Python for about 1.5 years privately.

And that's the difference. When you program for yourself - you can choose to use elegant and simple constructs, but when you program professionally the simplicity is paramount. Any language where functional programming is non-optional component is destined to be niche language at best, historic curiosity at worst. To push functional programming on people is the simplest way to make them hate you. Most programmers don't understand then functional programming and never will. They can drill few simple forms - and that's it.

Mildly functional then

Posted Aug 31, 2010 6:34 UTC (Tue) by man_ls (guest, #15091) [Link]

Let me answer both of you at the same time: well, I can understand why functional constructs are better when used sparingly. You don't have to filter(), map(), reduce() everything. But in certain occasions they are very useful.

Nonfunctional Java

Posted Aug 30, 2010 12:42 UTC (Mon) by alankila (guest, #47141) [Link]

> In practice, function-like constructs as those you propose are often
> forbidden, forcing developers to construct the "painstaking hierarchy";
> not to simulate functional programming, but to create the procedural
> equivalent.

Hmh. Java is restricted enough to begin with. I think anonymous inner classes are its most powerful invention, and some frameworks such as apache wicket strongly suggest the user to augment the framework objects as part of the action's definition. Doing these in any other way except as anonymous inner classes would be quite cumbersome, in fact.

Regarding Python's functional capabilities, it's again mildly amusing to know that Guido himself has wanted to remove "map" and "filter" from language, opting to provide special-purpose operations instead, such as sum or product. The list comprehensions were born as a kind of way to do filter and map without forcing the user to write lambdas. To me, it seems like you would rather draw the conclusion that procedural form of programming is actually preferred.

I agree with Guido that something like filter(lambda x: foo, y) is hardly very readable, but the [x for x in y if foo] replacement is, IMO, even less readable because the order of evaluations is now different from the lexical order, and ends up with me scanning the expression until I find the "for" that gets evaluated first, and I start to decrypt it from there. That these expressions are not written in execution order is astonishing to me.

Liking Java

Posted Sep 2, 2010 23:20 UTC (Thu) by Kamilion (subscriber, #42576) [Link]

Ah, that article pretty much summed up everything I dislike about Java.
Thanks for the link!

Google bails out of JavaOne

Posted Aug 30, 2010 14:24 UTC (Mon) by lenov (guest, #15428) [Link] (3 responses)

"given that java mainly runs as a web service"

Huh? I must be on a different planet. My organization (which business is related to computing) uses Java for about 50% of its code (and mostly Perl for the remaining). The field I am working in uses Java for about everything, from website to standalone graphical interface, including heavy numeric computation.

Google bails out of JavaOne

Posted Aug 30, 2010 14:27 UTC (Mon) by foom (subscriber, #14868) [Link] (2 responses)

> Huh? I must be on a different planet.

I think so, yes. :) AFAICT, Java is by far only used on the server-side. (and it is used quite a lot there!)

Google bails out of JavaOne

Posted Aug 30, 2010 14:41 UTC (Mon) by lenov (guest, #15428) [Link] (1 responses)

"I think so, yes. :) AFAICT, Java is by far only used on the server-side. (and it is used quite a lot there!)"

With all due respect, then you cannot tell far enough. It may be that in your field of activity this is the case. In scientific applications, Java is also used to code end-users applications, that you run by clicking on an icon in your desktop, or type ./foobar. A LOT of those applications are written in Java. In fact, since the beginning of the century, the duo C/Perl has been replace by Java/Python in many if not most of the training in computational biology for instance. The second for scripting, the first for everything else.

Google bails out of JavaOne

Posted Aug 30, 2010 15:27 UTC (Mon) by foom (subscriber, #14868) [Link]

> With all due respect, then you cannot tell far enough. It may be that in your field of activity this is the case.

No offense taken. Indeed, different planet, like you said!

Google bails out

Posted Aug 29, 2010 10:03 UTC (Sun) by gvy (guest, #11981) [Link] (1 responses)

Why exactly does Google insist on the "anti-opensource"-ness of Oracle's attack? As much as I like and dislike them both, manipulation is certainly not what's to like.

Google didn't argue against software patents in its Bilski brief

Posted Aug 29, 2010 15:57 UTC (Sun) by FlorianMueller (guest, #32048) [Link]

Oracle's patent assertion relates to software available under an open source license, so it is a use of patents against open source. Considering that open source is particularly vulnerable to patent attacks, that's regrettable.

However, this still isn't a fairy tale where one party is undoubtedly 'good' and the other undoubtedly 'evil'. It must become clearer what the intentions of the parties really are.

I wouldn't necessarily accuse Google of "manipulation" for pointing out the open source aspects of this, but I can understand if some are tired of it. The open source community is overwhelmingly against software patents, while Google owes its success in no small part to patent protection, considers its own search engine patents valid and valuable, to my knowledge has never granted any other company a license to its most important patents (which I call strategic exclusionary use and consider the worst way to use software patents), and in particular, Google didn't argue against software patents in its Bilski brief.

So if Google generally sides with other software patent holders to a greater extent than with the community, its call on the community at this point -- when Oracle is doing something that's perfectly in line with Google's Bilski brief -- must indeed be met with a healthy degree of skepticism until Google proves that it also advocates the broader community interest in connection with patents. In the Bilski case, Google just argued for its own interests in software (but not business method) patents and partnered with financial services organizations as opposed to open source entities.

What is wrong with C or C++ for mobile devices?

Posted Aug 29, 2010 18:07 UTC (Sun) by dskoll (subscriber, #1630) [Link] (12 responses)

I don't see why mobile manufacturers don't provide a C or C++ API and development environment. After all, GNOME, KDE and Xfce are almost entirely written in C, C++ or a mixture of the two, and they provide rich desktop experiences and cool graphical applications.

Most mobile apps are much simpler than their desktop cousins. About the only justification I can think of for using Java or some other sandboxable language is if the hardware doesn't provide memory protection between processes. But I don't believe that's the case with any modern smartphone CPUs.

What is wrong with C or C++ for mobile devices?

Posted Aug 29, 2010 23:31 UTC (Sun) by droundy (guest, #4559) [Link] (11 responses)

The explanation I've seen is that Dalvik bytecode is smaller than native code (each instruction is only a byte), so you save memory on resource-constrained devices. They were also able to do some pretty cool things to reduce the memory cost of library use.

I'm not sure whether those explanations hold water, though, they were just the closest I've seen to an explanation that I can believe.

What is wrong with C or C++ for mobile devices?

Posted Aug 30, 2010 13:28 UTC (Mon) by alankila (guest, #47141) [Link] (10 responses)

That the instructions per se are small is not necessarily a benefit when dealing with a garbage-collected languages that generally trade some memory for the freedom of programmer from having to manage memory explicitly. That does mean that you expect to see somewhat higher memory usage; how much higher depends entirely on how much memory you can afford before you have to run the GC cycle.

What I've seen of dalvikvm's behavior, it collects regularly and doesn't do it like Java would that launches collection cycles when some pool is exhausted. Maybe Dalvik works out a moment when nothing much is happening and collects then. That means the collection rate is approximately the same even if process heap was increased, however. Every GC cycle takes about 90 ms to do, almost regardless what the actual collected size is in bytes or # of objects, and there seems to be a few of them each second, perhaps more if application being run allocates a lot of objects.

However, I absolutely think that writing code in Java^WDalvik is much nicer than it would be in C/C++. The baseline of what's available and what can be expected to work is just set pretty high, and that's very nice for programmer. However, besides memory cost, there's also a CPU cost as Dalvik is still several times slower to what C implementation would be, but I expect Dalvik to get further optimizations in time.

Right now, for utmost performance, it's best to avoid allocating a lot of objects in core loops, and it's best to write any performance-critical parts in C. A normal way to accomplish this is to ignore this advice and forget about it if the code performs well enough, but if not, there's both a memory and CPU profiler to use to gain information about the application's behavior and where optimizations should be done.

What is wrong with C or C++ for mobile devices?

Posted Aug 30, 2010 19:02 UTC (Mon) by dskoll (subscriber, #1630) [Link] (9 responses)

Writing part of your app in Java and part of it in C or C++ seems the worst of both worlds to me. I think you can create decent C or C++ frameworks for mobile development, and I find it hard to believe you wouldn't get a significant performance improvement over a bytecode interpreter.

What is wrong with C or C++ for mobile devices?

Posted Aug 30, 2010 22:33 UTC (Mon) by alankila (guest, #47141) [Link] (8 responses)

Well, they aren't interpreting Dalvik anymore but compiling it to native ARM instructions on the fly. And I'd guess most people would really want to have the garbage collector, too, so that means that they will hate C/C++, almost regardless to what other goodies you would be able to offer. Oh, and doing something about those constant segfaults would be nice, too.

What is wrong with C or C++ for mobile devices?

Posted Aug 31, 2010 1:33 UTC (Tue) by trusmis (guest, #47355) [Link] (1 responses)

It's easy.
If it is your platform and you program the libraries the programs will use, you also control how they can be used.
You can just to unique_ptr everything and let RAII take care.
Just discourage the use of manually handed pointers.
People will follow suit, if they don't it is they seg fault problem. Not worse than a Java exception or a python runtime exception.

What is wrong with C or C++ for mobile devices?

Posted Aug 31, 2010 14:10 UTC (Tue) by alankila (guest, #47141) [Link]

First time I heard of unique_ptr. It may be that C++0x, which seems to contain it, will be a vastly better language than the older form of C++. I still think that almost no matter to what *_ptr<T> you offer to people, it's going to feel far worse than simply not having to care about the whole thing at all.

What is wrong with C or C++ for mobile devices?

Posted Aug 31, 2010 2:39 UTC (Tue) by dskoll (subscriber, #1630) [Link] (5 responses)

Well, they aren't interpreting Dalvik anymore but compiling it to native ARM instructions on the fly.

There's still overhead, and if it's the case that you end up with native ARM instructions, you lose much of the supposed memory savings.

And I'd guess most people would really want to have the garbage collector, too, so that means that they will hate C/C++, almost regardless to what other goodies you would be able to offer.

Maybe, but there are plenty of large apps in the desktop world that get by just fine without GC (Mozilla, OpenOffice, Chrome, KDE, GNOME, Xfce).

Oh, and doing something about those constant segfaults would be nice, too.

If there are "constant segfaults", the software is defective, and changing languages won't help.

What is wrong with C or C++ for mobile devices?

Posted Aug 31, 2010 14:20 UTC (Tue) by alankila (guest, #47141) [Link] (3 responses)

> you lose much of the supposed memory savings.

True. I don't think the code size is very interesting anyway, because the code size will probably be small compared to the data on the program, and the representation of the data files in memory.

> large apps in the desktop world that get by just fine without GC

Yeah. Well, they have refcounting schemes or something to replace GC, if not a real GC. In practice large applications create objects and place them in various datastructures or share these objects between other objects, and therefore need a general way to track when an object becomes unnecessary anyway. Refcounting is just "GC" but poorly done. Isn't Mozilla famous for its memory leaks, anyway?

> changing languages won't help

Yes, well, let's say that Java gives you a stack trace, and C gives you a segmentation violation message and maybe a stack trace if you are lucky, but the stack trace mostly consists of memory addresses due to missing symbols. The practice of stripping C programs should really be ended.

What is wrong with C or C++ for mobile devices?

Posted Aug 31, 2010 15:45 UTC (Tue) by dskoll (subscriber, #1630) [Link] (2 responses)

That's really no big deal. All you need to do is keep an unstripped version of the program around on your development machine, and then use that to interpret the stack trace. I remain unconvinced that Java offers advantages over C or C++ for mobile development.

Isn't Mozilla famous for its memory leaks, anyway?

Yes, sure. But X (as in the X server) is not, nor are most GNOME, KDE and Xfce programs. You just need to be careful.

What is wrong with C or C++ for mobile devices?

Posted Aug 31, 2010 16:48 UTC (Tue) by bronson (subscriber, #4806) [Link] (1 responses)

I think it's almost completely due to security. C/C++ apps can be nightmarish to get right. Buffer overflow exploits are still being found daily. Anyone who says that's not a problem in our era of strong memory protection isn't considering our era of dbus, bluetooth, pulseaudio, etc daemons.

Java is a pretty bad language (just my experience) but I'll say this: its approach to pointers means *way* less presence on CVE. And that alone is reason enough to choose it over C/C++.

What is wrong with C or C++ for mobile devices?

Posted Aug 31, 2010 18:08 UTC (Tue) by dskoll (subscriber, #1630) [Link]

Yeah, OK. You've got me. :) The security problem is an important one.

What is wrong with C or C++ for mobile devices?

Posted Aug 31, 2010 15:46 UTC (Tue) by Tobu (subscriber, #24111) [Link]

Mozilla has a garbage collector on the javascript side (javascript being the bulk of the firefox codebase), refcounting on the XPCOM side, and a cycle collector that glues them together. They would very much like to change to a single GC accross the board.

With many applications becoming mixed-languages (which is how gnome is evolving, look at gnome-shell for a radical example), garbage collection should become more prominent as a sensible way to free up cross-language reference cycles.