Earlier quoted context omitted.
Generalizations about which technique beats the other technique reflect a lack of technical maturity. Both have advantages, and you're doing a disservice by advocating the use of one or the other exclusively ignoring differences in environment, circumstances, and workload.
Fair. But having worked on both and currently working on AOT I'd say I should be biased for AOT not against it... Startup time/warmup is obviously a well known JIT weakness but if its well written its just really hard to beat. E.g. if(x) { invokeMethodX() } else { invokeMethodY() } Say x is related to user details/preferences and for a specific install will never change... AOT can't do anything about that... JIT can…
Mysterious Android codebase commit
151–160 of 170 posts
Re: Mysterious Android codebase commit
#152Earlier quoted context omitted.
Not startup but warmup (i.e. the time until the application is fully optimized). There are other problems with a JIT on small devices, such as increased memory and energy consumption (each may be significant or not, depending on how the JIT works). I am a big fan of JITs, but as with everything in software, it is a tradeoff.
Increased memory consumption and reduced page sharing between processes using the same code means lower performance. Memory bandwidth and cache capacity are a much bigger bottleneck than CPU throughput for most use cases. A JIT compiler is not competitive in performance with an AOT compiler if both are using the same code generation implementation. And profiling is limited in what it can do, especially when AOT compi…
If a JIT uses the same code generation as an AOT, it will work as an AOT, namely, only when the application starts, without additional burden during its runtime. Most good JITs use profiling information, which is collected at runtime -- this has some memory overhead, but results in better code.
> And profiling is limited in what it can do, especially when AOT compilation with PGO as used by projects like Firefox is considered.
Modern JITs are like _very_ sophisticated PGO AOTs, but they have true profiles exposed to them. Besides, the overhead for even a good JIT is not that large, it's just that on mobile devices even a bit more RAM is more than you're willing to afford.
Re: Mysterious Android codebase commit
#153Earlier quoted context omitted.
> [1]: I am willing to bet that very few people understand what the Oracle v. Google court case is all about, And what it was about?
First, we should separate the motivation for the lawsuit from the legal arguments. Corporations don't go to court to win legal arguments; they go to court to defend or promote their business. I) The motivation for the lawsuit was that at the time, Java's main revenue stream was licensing Java IP (either an actual implementation or the permission to implement the spec) for use in mobile devices. That was how Sun made…
No thanks. Free software is based on irrevocable legally-granted rights, not some horrible company's largesses. If OpenJDK really is free software, I should be able to hack it such that it no longer conforms, stick it in a phone, and ship millions of copies without being sued.
Google's case isn't unusual at all. The same logic applies to anyone reimplementing an existing API with anything but bug-for-bug compatibility. Your view means that we can improve nothing, delete nothing, and deprecate nothing, since as soon as an API implementation diverges from the original, it's suddenly not for "interoperability", but rather an illegal appropriation of somebody's revenue stream? That argument is blatantly inconsistent with free software principles.
I'm going to give you the benefit of the doubt and assume that you're just an ardent Oracle fan, not a paid shill. It's really hard to tell the difference sometimes. Please reconsider the effect Oracle's litigation has on the entire software ecosystem. Consider that we wouldn't even have Unix if its view prevailed. You should be ashamed of yourself.
Re: Mysterious Android codebase commit
#154Earlier quoted context omitted.
> That's only because the term "API" -- until very recently -- was only used to describe language-level API, while what today is known as a web API has always been called a protocol, so don't let the recent overloading of the term confuse you. A protocol is not the same as an API and I don't hink that the, for example, Google Maps interface is a protocol > More to the point, the reason copyright may apply to APIs but…
> A protocol is not the same as an API and I don't hink that the, for example, Google Maps interface is a protocol However you want to call it, unlike a "proper" API, it is not of the right form to be copyrighted, regardless of the ruling pertaining to "proper" APIs. > NO, the appeal ruling had nothing to do with Google arguments about fair use. The court didn't rule on fair use, but it did address it. They said that…
Still waiting an explanation about web API's not being a proper API. They are not protocols
> That danger had existed even before the court case; the ruling simply did not lift it. Fair use is granted neither automatically nor in court. It is a defense to be used if you are sued
So anyone is on danger of being sued by a copyright holder of an API.
Re: Mysterious Android codebase commit
#155Earlier quoted context omitted.
First, we should separate the motivation for the lawsuit from the legal arguments. Corporations don't go to court to win legal arguments; they go to court to defend or promote their business. I) The motivation for the lawsuit was that at the time, Java's main revenue stream was licensing Java IP (either an actual implementation or the permission to implement the spec) for use in mobile devices. That was how Sun made…
You're saying that I can do whatever I want with OpenJDK until it cuts into Oracle's revenue stream, at which point Oracle will sue me and keep suing me until they find an argument that shuts me down? No thanks. Free software is based on irrevocable legally-granted rights, not some horrible company's largesses. If OpenJDK really is free software, I should be able to hack it such that it no longer conforms, stick it i…
Not at all. I'm saying that you can do whatever you want with OpenJDK/Java, but if you don't abide by either of their licenses -- the commercial or the open source license -- Oracle will come after you, but probably only if you pose a serious threat to them, or else they wouldn't bother. Do you know of a company of Oracle's size that acts any differently? In fact, Google expected the timid Sun to come after them, and it was only Sun's decline that stopped them.
> Free software is based on irrevocable legally-granted rights, not some horrible company's largesses.
It is, but free software does have a license, and you don't get those rights until you comply with the license. That applies to OpenJDK just as it does to Linux, both released under the same license, BTW. Google is adopting Java's open-source license just now. They had their reasons, but they most definitely did not until now.
> I'm going to give you the benefit of the doubt and assume that you're just an ardent Oracle fan, not a paid shill
I am far from a fan. Oracle is a terrible company, and I wish it was a different company that had bought Java. But Google is worse. So I guess you could say that in this case, Oracle is the lesser of two evils. But what really bugs me is that the huge Google PR machine has done everything in its power (and quite successfully) to confuse everyone about this case, and convince people that the lawsuit has any bearing on them whatsoever. The ferocity Oracle's legal team is legendary, but it doesn't come close to the legendary manipulativeness of Google's PR. Employing paid shills is much more a Google thing than an Oracle thing; Oracle prefers lawyers.
I was, however, a fan of Sun.
> Please reconsider the effect Oracle's litigation has on the entire software ecosystem.
And what effect is that? I know that Google tries to convince people it has far-reaching effects, but the actual ruling doesn't seem to imply any of that.
> Consider that we wouldn't even have Unix if its view prevailed.
That's just Google PR talking. Let me make this short and hopefully clear: Google copied part of an Oracle/OSS API and broke compatibility in order to make a profit. They didn't try to build an interoperable alternative to Sun's Java, but to get into a ready-made market of Java tools and developers. The question of API copyrightability had never been settled, and whoever would have come after Unix after the ruling would (and certainly could) have done so before. Even if APIs are copyrightable, there's still fair use, two of those defenses -- interoperability and non-profit -- would apply to most implementations, but possibly not to Google's.
Sure, maybe APIs shouldn't be copyrighted (again, this is only language-level APIs) -- I can see good argument for either side -- but the effect of their copyrightability on the software industry is at worst minimal, and is most likely nil because of a thing called "fair use". I am not aware of another case where a replication of an API was done both not in order to build a compatible product and for profit.
Besides, their "view" wouldn't have even been made (as I said, Oracle didn't set out to make a legal point) if Google had only licensed Java in one of the two available ways, one of which they are finally doing now and the other they could have probably afforded at the time. Google knew full well that Sun would come after them, but hoped they could win in court.
Re: Mysterious Android codebase commit
#156Earlier quoted context omitted.
> A protocol is not the same as an API and I don't hink that the, for example, Google Maps interface is a protocol However you want to call it, unlike a "proper" API, it is not of the right form to be copyrighted, regardless of the ruling pertaining to "proper" APIs. > NO, the appeal ruling had nothing to do with Google arguments about fair use. The court didn't rule on fair use, but it did address it. They said that…
> However you want to call it, unlike a "proper" API, it is not of the right form to be copyrighted, regardless of the ruling pertaining to "proper" APIs. Still waiting an explanation about web API's not being a proper API. They are not protocols > That danger had existed even before the court case; the ruling simply did not lift it. Fair use is granted neither automatically nor in court. It is a defense to be used i…
It's not that they're not APIs (you can call anything you want an API -- copyright law doesn't care what it's called), but because they don't have a fixed form. In order to copyright something you need it to be a particular fixed text (or image, or recording). There is no such text for web APIs. You can come up with multiple texts (or images) all describing the exact same API. That is not the case for "plain" APIs. Plain APIs -- like all code -- do have a fixed form. But no fixed form means no copyright.
The very beginning of the definition of US copyright says[1]: "Copyright protection subsists, in accordance with this title, in original works of authorship fixed in any tangible medium of expression, now known or later developed, from which they can be perceived, reproduced, or otherwise communicated, either directly or with the aid of a machine or device" (emphasis mine). There are other requirements, but without a fixed form no copyright may apply[2].
The bits of text comprising the names of JSON fields, while fixed, are too short (and lack the necessary structure) to be considered "a work" for copyright purposes.
> So anyone is on danger of being sued by a copyright holder of an API.
That has always been the case (because it had never been settled that code APIs are not copyrightable). A different ruling may have removed that particular threat, but it didn't. It certainly didn't add new legal threats.
But let me give you this advice: If you're a big company with deep pockets and you're coming after the income of another big company with deep pockets using something that may be law-related -- expect to be sued. In fact, I don't need to give you this advice because if you're a big company with deep pockets you probably know this, as you're already in the habit of suing and/or being sued all the time.
[1]: https://www.law.cornell.edu/uscode/text/17/102
[2]: The law also says: "In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work", which is the source of Google's argument that copyright doesn't even apply to actual APIs, but that's a whole other discussion, and is far from simple. E.g. a book's table of contents could also be argued to be a procedure or a concept, yet it is certainly copyrighted. Oracle said that an API is like a table of contents. There are good arguments for arguing either way. But again, not having fixed form stops the discussion in its tracks.
Re: Mysterious Android codebase commit
#157Earlier quoted context omitted.
You're saying that I can do whatever I want with OpenJDK until it cuts into Oracle's revenue stream, at which point Oracle will sue me and keep suing me until they find an argument that shuts me down? No thanks. Free software is based on irrevocable legally-granted rights, not some horrible company's largesses. If OpenJDK really is free software, I should be able to hack it such that it no longer conforms, stick it i…
> You're saying that I can do whatever I want with OpenJDK until it cuts into Oracle's revenue stream, at which point Oracle will sue me and keep suing me until they find an argument that shuts me down? Not at all. I'm saying that you can do whatever you want with OpenJDK/Java, but if you don't abide by either of their licenses -- the commercial or the open source license -- Oracle will come after you, but probably o…
What's wrong with copying part of an API? You yourself admitting that I can do whatever I want with OpenJDK, including copying only part of it. I can then use this copy to make a product that turns a profit. If Oracle will sue me to this practice, then Google, not Oracle, is on the right side here.
Re: Mysterious Android codebase commit
#158Earlier quoted context omitted.
> You're saying that I can do whatever I want with OpenJDK until it cuts into Oracle's revenue stream, at which point Oracle will sue me and keep suing me until they find an argument that shuts me down? Not at all. I'm saying that you can do whatever you want with OpenJDK/Java, but if you don't abide by either of their licenses -- the commercial or the open source license -- Oracle will come after you, but probably o…
> That's just Google PR talking. Let me make this short and hopefully clear: Google copied part of an Oracle/OSS API and broke compatibility in order to make a profit. They didn't try to build an interoperable alternative to Sun's Java, but to get into a ready-made market of Java tools and developers. What's wrong with copying part of an API? You yourself admitting that I can do whatever I want with OpenJDK, includin…
Absolutely, as long as you comply with the open source license, which is plain GPL in this case (just like Linux). Google didn't -- until today -- as they released Android under the Apache license rather than the GPL license. They always had the option of going GPL -- in which case Oracle would have not come after them -- but they didn't want to[1].
> If Oracle will sue me to this practice, then Google, not Oracle, is on the right side here.
Google did not comply with the license (either license, actually). Their legal claim was that they don't need to comply with any license, because if APIs aren't copyrighted, then they're not Oracle's to give (i.e. to license). That legal claim, too, is perfectly reasonable (as is its opposite), but it seems clear to me that it was Google who was at least ethically, if not legally, wrong in this case.
In any event, Java is also licensed with a standard open-source license (through OpenJDK), that you can use -- wholly or partially -- for any purpose whatsoever; Oracle has never sued anyone for using its code or APIs in this way for whatever purpose.
---
[1]: Which is why people in the free software community, even though they believed copyright shouldn't apply to APIs, were pissed off at Google for going to great lengths (and basically asking for this lawsuit) all in order to avoid the GPL option, which has been open to them all along.
For example, here is what the FSF had to say in 2010 on the matter (they were against Oracle's lawsuit because one of Oracle's tactics was to claim software patent infringement, which the FSF is against, as am I):
"Oracle's lawsuit threatens to undo all the good will that has been built up in the years since... Unfortunately, Google didn't seem particularly concerned about this problem until after the suit was filed. The company still has not taken any clear position or action against software patents. And they could have avoided all this by building Android on top of IcedTea [an early OpenJDK distribution], a GPL-covered Java implementation based on Sun's original code, instead of an independent implementation under the Apache License... It's sad to see that Google apparently shunned those protections in order to make proprietary software development easier on Android." (emphasis mine. Source: https://www.fsf.org/news/oracle-v-google)
I will add that while Oracle has treated some of its acquired open-source projects abominably -- e.g. OpenSolaris :( -- it has been very good to OpenJDK (more than Sun), so much so that virtually all development on the runtime at Oracle is done on OpenJDK these days. Also, Oracle still maintains more open source software than Google (and possibly any other company save for RedHat), but I'm not too hopeful about its future treatment. However, OpenJDK is now way too big for Oracle to ruin even if they tried.
Re: Mysterious Android codebase commit
#159So Lambda's are finally comming
Re: Mysterious Android codebase commit
#160Earlier quoted context omitted.
> However you want to call it, unlike a "proper" API, it is not of the right form to be copyrighted, regardless of the ruling pertaining to "proper" APIs. Still waiting an explanation about web API's not being a proper API. They are not protocols > That danger had existed even before the court case; the ruling simply did not lift it. Fair use is granted neither automatically nor in court. It is a defense to be used i…
> Still waiting an explanation about web API's not being a proper API. It's not that they're not APIs (you can call anything you want an API -- copyright law doesn't care what it's called), but because they don't have a fixed form. In order to copyright something you need it to be a particular fixed text (or image, or recording). There is no such text for web APIs. You can come up with multiple texts (or images) all…
You're joking, isn't?
> The bits of text comprising the names of JSON fields, while fixed, are too short (and lack the necessary structure) to be considered "a work" for copyright purposes.
What are you talking about? Do you really know what an API is and how web services are defined? You're confusing argument names with the API definition.