1,328 karma · joined May 2, 2015
Lenovo - we don't charge $257 to fix your space bar.
>This is fun and is easier than optimizing gcc / llvm, since the majority of the Go compiler, runtime and standard library is written in Go
Amusing how the language looks so much like Kotlin - a language released in 2011 and 3 years before Swift.
My AS Emulator starts in about 20 seconds from a cold start and in a couple seconds from a saved image state.
>If it works the first time you are lucky, if it breaks you are on your own.
The people that work on the AS Emulator are on the Androidev reddit quite regularly to answer any questions regarding new releases.
How are Java/Kotlin apps non native in Android when they're first class languages that are compiled to native code? AS also supports Android C/C++ development if you need bare metal speed and complete control.
>The two ways people develop apps seem to be going fully native, or using web "masks" like react native, outright web directly, or something like apache cordova. Neither of which seem to be the focus of android studio.
Last time I viewed the percentages of what frameworks Android apps were developed in these web based frameworks ranked extremely low.
You probably meant "embracing", but a funny autocorrect nevertheless.
You mean the same AdBlock Plus that allows selected ads to bypass it so long as you paid them?
No it isn't. According to this independent test not only did Edge lose to Chrome, but it was also wildly inconsistent.
https://www.cnbc.com/video/2018/05/10/vc-draper-theranos-fou...
I just realized you're counting the Others section and incorrectly lumping them into 2018.
It would seem you also neglected to read Wikipedia's banner above the Other section that stated:
This section is missing information about the discontinuation date of each product in this section. Please expand the section to include this information. Further details may exist on the talk page. (October 2013)
And Microsoft has abandoned over 220+ products and services.
Please know that Apple will continue its work with law enforcement. We share law enforcement's concerns about the threat to citizens and we work closely with authorities to comply with legal requests for data that have helped solve complex crimes. Thousands of times every month, we give governments information about Apple customers and devices, in response to warrants and other forms of legal process. We have a team that responds to those requests 24 hours a day. Strong encryption does not eliminate Apple’s ability to give law enforcement meta-data or any of a number of other very useful categories of data.
>My fear is this -- once Google has control of the web, they can turn off huge parts of it for whatever reason, however thoughtless, and without disclosing why.
This person has either been watching too many movies that depict the web as a place where IP's can be traced by writing Visual Basic GUI's or doesn't understand how the Internet works.
>Given how hard you support Google's fragmentation actions against the Java eco-system, your OS also uses C without libc.
Since Android doesn't run Java apps or use the JVM there is no fragmentation.
I'm currently using Chrome on a 4GB system with 10 tabs open with no performance issues or fans screaming. To claim that Chrome is borderline unusable on 8GB of RAM is a lie.
It didn't require a TCK license because Apache never called it Java nor did Google need permission to use it on embedded devices.
>Says the Google employee.
What a petty response. You're blaming the failure of Sun on Google. When in reality the failure of Sun can clearly be traced to their poor business decisions and acquisitions. Sun had a lot of potential, but they were let down by incompetent leadership.
>Why did not Google buy the Java assets from Sun, given the deep investment on Android?
Did Sun offer to sell the Java assets to Google? I'm not aware of such an offer ever being made. If the offer was made then I agree that Google should have purchased the Java assets solely.
>Ah now you state that Google did fork Java.
The only thing I'm claiming is that Google did indeed fork the OpenJDK as they are allowed to do.
>Because OpenJDK is to Java like libc is to C, libc++ to C++, DOM APIs to JavaScript, .... Forking while pruning the available API breaks the compatibility with existing code and fragments the eco-system.
The OpenJDK is an open source project that Google is allowed to legally fork and use just as long as they don't call the fork Java.
>Exactly what Sun managed to prevent with J++, whereas with Android Java they were a bit low on cash.
You're forgetting to mention a key difference. Microsoft called their extended version Java. Google does not refer to their fork as Java.
>Whatever Oracle has chosen as attack vector is little relevant for the fact that I cannot take a random piece of Java code and be assured it compiles and runs on Android.
Google doesn't call their implementation Java so I don't see why you would think you should be able to run any Java app on Android.
The Apache Harmony code base is an open source, free Java implementation, developed by the Apache Software Foundation that is licensed under the Apache License 2.0. Google had every right to use the Apache project according to the terms of the license.
>Thanks to that, Sun lost what might have rescued from insolvency. Which Google, while thinking that they finally got rid of Sun did not bothered to try to save.
Sun is solely responsible for their bad business decisions due, in most part, to their incompetence. Issuing a license to Google would not have saved them from being acquired by Oracle.
>Yet Android does not use 100% of OpenJDK, rather they are adding little pieces of it in each Android version.
I wasn't aware that you had to implement 100% of an open source project if you forked it. Can you cite where that's a requirement?
>Thus Android uses a forked version of OpenJDK, with everything that Google doesn't care removed from it.
The Android SDK uses a forked subset of the OpenJDK. And why wouldn't Google remove things they didn't need like AWT, Swing, etc.
>The fact that they use ART is an implementation detail, some Java certified JVMs for embeded deployment also have tooling to convert to their optimized implementation instead of using .class files.
No it's not. There is no association architecturally or IP related between the JVM and ART. If there was then Oracle would not have lost every one of their JVM IP patent claims they asserted against the Android runtime.