Android Studio 4.0
android-developers.googleblog.com
android-developers.googleblog.com
Or finally fix the activities and fragment mess?
(Regardless, reimplementing Windows APIs without documentation and writing a simulator for a phone OS are two completely different endeavors.)
Unfortunately, there is only an aarch64 emulator for Android 7, which does not start on my system
What does that mean? The x86 system image can run arm code? I will try that (might get confusing if there is an arm and x86 lib in the apk).
I have been using the image without google apis to save space, because my sdd is almost full
Does it reject invalid arm? I wrote my app in Pascal, and the FreePascal compiler often generates invalid assembly. Especially because I need to use the nightly build, because the last stable release does not support aarch64
(Also AFAIK illegal instructions are still validated and trapped as SIGILL or SIGSEGV)
hw.audioInput=no hw.audioOutput=no
to every AVD I create. Otherwise, the Android Emulator uses 100% CPU all the time, even when it's been idle for minutes.
I'm far from the only one having the problem, see https://stackoverflow.com/questions/37063267/high-cpu-usage-...
I'm on a Macbook Air 2014, Intel i5, 8GB of RAM, 500GB SSD. Hardware acceleration, etc. all enabled.
https://drive.google.com/open?id=1sXEQcoiNpe3Lj8yeaKLasTjqlGQwy4Oi
install repo from depot_tools https://www.chromium.org/developers/how-tos/install-depot-to...
pip install absl-py
pip install urlfetch
mkdir emu
cd emu
repo init -u https://android.googlesource.com/platform/manifest -b emu-master-dev --depth=1
repo sync -qcj 4
cd external/qemu
python android/build/python/cmake.py
# run
objs/emulator -avd avdName -no-snapshot
# when it spins:
# method 1: go to activity monitor -> sample process, send over the result
# method 2: lldb
lldb
process attach --pid <pid-of-qemu-system-<arch>>
bt all #send it over
# method 3: guest process taking CPU
adb shell top$ANDROID_SDK_ROOT, if not set, should be set to the SDK location in Android Studio > Preferences > Android SDK (SDK path will show up there).
Set it in your ~/.bash_profile too so it's there next time for running the emulator from the command line.
The AVD config.ini can be found in ~/.android/avd/nameofAvd.avd/config.ini .
I have to use MacBook 13 (2019) in my current project, and it's having troubles with the emulator. Not sure if it's about the hardware or macOS inefficiencies, but I can't wait to get back to my Linux desktop where the emulator is buttery smooth, almost feels like a part of the system itself.
I don't want to upgrade the PC as I love it the way it is and it's enough for everything else. I feel like I'd like to make a simple app for my phone occasionally (just for fun and to make something in my life easier) but emulation seems impossible.
What I have resorted to is writing single-page JavaScript apps and running them in the browser so I can debug them in the host browser instead of an emulator.
Windows and Linux themselves in a VM is probably reasonably ok on your hardware because both of those OSes are built to run on non-current hardware (especially Linux; I'm running Debian buster with a current kernel on a circa 2010 single-core ARMv5 CPU with 256MB of RAM with no problems).
Android doesn't target old hardware; I wouldn't expect a current release to run all that well even on a four-year-old phone, let alone a 10+-year-old laptop with virtualization overhead.
Also the usual stuff applies: be sure you have your system's virtualization extensions enabled if it has any, use the x86 Android emulator image with hardware accel enabled, not the ARM one, etc. But that still may not be enough.
Just curious, which board is that?
i'm with you that android emulation is pretty slow, but your machine is reaching near parity with many of the devices that run the platform you're trying to emulate.
it's nearly always the case that an emulator host has to have a significant performance margin over the guest just to account for the inaccuracies/inconsistencies/hacks that are involved in mimicking a system on a dissimilar hardware platform.
EDIT: Also make sure you've enabled VT-x if your laptop has it.
An Android app I want to write is going to be a single form with some text fields and some buttons, it will have simple logic but it needs to run in background, be able to read a sensor, read/write some SQLite/CSV data and play a sound occasionally. No fancy graphics bells and whistles.
This seems like a very simple task to handle, I bet it's not going to take much RAM or CPU.
Why is it so hard to emulate?
- Galaxy S9+ (2018): 6GB
- Galaxy S10 (2019): 6 or 8 GB
- Galaxy S10+ (2019): 8 or 12 GB
- Galaxy S20 (2020): 8 or 12 GB
- Galaxy S20 Ultra (2020): 12 or 16 GB
- OnePlus 3 (2016): 6 GB
- OnePlus 8 (2020): 8 or 12 GB
- LG G7 ThinQ (2018): 4 or 6 GB
- LG Velvet (2020): 8GB
- Pixel 4 (2019): 6GB
- Xiaomi Pocophone F1 (2018): 6 or 8GB
- Huawei Mate 20 (2018): 4 or 6 or 8GB
- Sony Xperia 1 (2019): 6GB
- Moto Razr (2020): 6GB
You're trying to emulate an entire OS here. Android 10 requires a minimum of 2GB of RAM just on its own now. You have overhead for the emulation software itself on top of that, in addition to the memory needed by your computer's OS, your IDE, your browser, etc. Android Studio alone requires a minimum of 1GB and, at least in my experience, it will use that within 5 minutes of opening up.
Not to mention, even budget phones today are at least twice as fast as the CPU you're running.
You can't expect emulated software to run well on a computer that barely even meets the minimum requirements for that software. It's ludicrous.
Ok. I can see no reason to care about such though. What the heck do they need that for?
> You're trying to emulate an entire OS here.
But I emulate desktop Linuxes and Windows without problems - that's entire OSes too.
> Android 10 requires a minimum of 2GB of RAM just on its own now.
Why? What does it need this much for? Anyway, I can reserve 2GB of RAM now and I'm sure I'm not going to notice too much drop in performance.
> You can't expect emulated software to run well on a computer that barely even meets the minimum requirements for that software. It's ludicrous.
As for the app - I'm sure it can't require anything near that much. As for the OS - why does Android have to require so much more than Linux and Windows do?
BTW my actual phone (Galaxy Note 3) runs Android 9 on 3 GB RAM perfectly. I never tried 3D games but everything else is blazing fast. I've been updating it (Android 4-5-6-9) for years and never noticed a glitch.
> Why? What does it need this much for?
As a developer, that shouldn't matter to you. Only that it _does_ require that much. You can assume that your users will have 4GB of memory in almost all cases now, whether you agree with it or not. Your opinion on the _why_ is irrelevant, frankly.
If you can't provide that much to the emulator, you can't expect to run it smoothly. There is no magic solution to this. These things require resources that your computer does not have. If you want it to run better (or even at all), get better hardware. That's all there is to it.
Core2Duo was released over 13 years ago, and discontinued over 7 years ago.
Time to think about upgrading before complaining about performance issues. Especially for emulation.
Also I don't believe that PC isn't painful to use for everything else. I had a core2duo a while back and it was slowish back then.
Then why is desktop Linux and Windows emulation not nearly as slow? Windows 7+ emulation is slightly slow, especially running VisualStudio on an emulated Windows7 is painfully slow (while perfectly swift on non-emulated) but still usable if you have enough patience (Android emulation is absolutely unusable). Emulated (VirtualBox on a Linux host) Windows XP runs even faster than on bare metal.
> Also I don't believe that PC isn't painful to use for everything else. I had a core2duo a while back and it was slowish back then.
You probably did something wrong. It's not just painless, it's perfectly swift (both with the latest KDE Plasma and with Windows 7). I have a modern PC at the office (late pre-Ryzen AMD, 8GB RAM, Win10) and its perceived performance is the same. It even feels more slow (less responsive) than the Core2Duo occasionally but I blame that to Windows10.
Of course I only mean basic tasks like browsing the web, watching videos (1080p or less), juggling files and writing code (VisualStudio, IntelliJ) for small projects. Obviously any modern CPU will beat Core2Duo in video transcoding, modern games etc.
VT-D makes your Core2Duo better able to emulate Windows or Linux in hardware, but not Android.
Like I said, I don't believe that a Core2Duo isn't slow for everything you mentioned. I had one at home. I wasn't doing anything wrong - I know how fast it isn't - we had hundreds at my work. Have you noticed that other commenters are saying the same thing about Core2Duo speed as me? You must have more patience to wait for your PC than myself and the other commenters.
The reason I replaced my Core2Duo was because it was slow, and I replaced it around 8 years ago!
And what issues did you have with activities and fragments?
Oh, on those. Compared to iOS and ViewControllers, they just isn't a comparison. Starting them? Oh, can I do new Activity()? Nope, use this Intent thing. Rotation? Good luck! Passing data around? I have to use a bundle? Why can't I set a variable inside, like any other object?
Just to start. :)
You can just set variables like normal Java just fine. The bundle thing is only necessary to preserve data across process deaths.
Your best bet to pass data around is to... not pass it but rather use a sophisticated DI setup where you can set up shared objects that live in a certain scope. Of course, you can add parameters to a bundle with some boilerplate, but that's not a great idea if the serialization overhead hurts you.
An Android app is a Java app using a set of special APIs. Why can't it run on a host JVM given some libraries implementing the same APIs? I'm not interested in the NDK.
That's a hideously huge API surface to double-implement - with a new and unique set of bugs reducing it's usefulness in CI builds - for slightly improved performance in a relatively niche dev edge case (!ndk android dev without android hardware.) You'd also need to skip conversion to DEX format (or convert back) to run on a standard JVM.
But your suggestion isn't technically impossible. You could (re)implement the subset of APIs your application happens to use yourself, if you really wanted to go down that route - which by virtue of being a much smaller subset of the APIs than the entire Android Java API surface, wouldn't even be practically impossible.
The only exception to that is libsystem_{pthread,kernel,platform} because those form the kernel's ABI boundary. Libraries like libc, libdispatch, et al are the iOS build and use the iOS ABI.
If your desktop can't replicate the performance of your phone, it's misconfigured or seriously underspecced.
During typing this comment I nearly lost my mind because my macbook shift key is playing up and other keys are doing key repeats. I think I might go insane, stupid butterfly design
With full virtualization, the contact surface is restricted to a few low level bits in the kernel along with a few HALs/drivers that need to talk to the host for meaningful/fast I/O, like input/network/graphics, and everything else can be kept stock with no modification. This allows us to ship largely the same binaries that would go on a dedicated Android device and have it be able to run on windows/macos/linux easily, and it's how we've been able to keep up with the pace of yearly Android releases.
Edit: Oh and note that we are totally aware of and bummed out by emulator's increasing resource usage as android version bumps up, to the point we're afraid that the next one will finally be the one that really needs all resources of a modern PC; as such, we're looking into ways to minimize the cpu/ram/disk footprint of the system images, keeping only the bits that are actually needed for testing apps (with Google Play Services, and being better at maintaining/promoting more stock AOSP images in the case where GMS isn't needed)
So this is basically the simulator situation, but with easier management of which libraries the guest userspace can dlopen and files to read()/write().
It's much like current Android-on-ChromeOS capabilities where containers are used to isolate where the "guest" userspace libraries are stored, so that it's not necessary to interop well with things like the host version of libc for example.
However, the problems come when considering the interface to the host kernel and hardware. Here are just two of the showstoppers:
1. Android expects to run on a particular range of kernel versions and configs each release. Fidelity is sacrificed to run with a wide range of Linux host kernel configurations. It's also easy for components on the host system such as SELinux to interfere with guest operation (and Android itself expects to use its own version of SELinux...so which one wins in the end?).
2. Further customization in the guest userspace needs to be made to account for needing to interop with a regular Linux system; e.g., input/network/display will be much more code that touches various parts of guest userspace and potentially hurts fidelity versus the VM abstraction where they are fake hardware and no customization of guest userspace is needed.
There are also isolation issues that involve more delicate dances, such as how to prevent runaway resource usage in the container from hogging the whole system (VMs merely waste the #vcpus + RAM dedicated to them; while that can be a lot compared to the host, it's explicitly controllable).
These problems sound less serious on the surface versus porting the Android framework directly to the host OS, but in the end it's basically the same level of essential complexity; containers just let you remove the incidental complexity of guest userspace libraries leaking into your /usr/lib and interop w/ your filesyste.
And once we try to run on non-Linux systems we're back at square one needing to port all userspace code to the host OS (Unless you're running Docker on macOS/Windows in which case you'd be creating a VM again, sacrificing all the benefits of containers versus VMs while keeping the complex customizations).
This is probably why Microsoft is pushing WSL2, ChromeOS skipped Android 10 support and is looking into ARCVM, and anbox is still running Android 7.1.1 (w/ plans to update but skipping releases in the meantime).
And yeah, as of Android Studio 3.x (was waiting for the official 4.0 release), it was trying to nudge towards using the Google Play Services images pretty hard.
But this is pretty much what Android Emulator is - a fullish VM on a Linux base.
On all my PCs it is faster to build to device than having to deal with the emulator competing with Android Studio for hardware resources.
Not everyone has Google level budgets for hardware.
Neither of which required anything resembling a latest generation hardware. Try it again before you pretend your experiences years ago are still relevant.
I tell you why, you have forgotten to mention that "Extended Page Tables (EPT), and Unrestricted Guest (UG) features" are also required.
> Not everyone has Google level budgets for hardware.
Given that my current one runs Windows 10 64bit Pro, Visual Studio 2019, OpenJDK 14, clang 10 and Eclipse 2020‑03 just fine, I am not upgrading a perfectly working computer just to make Android emulator, or are you offering to get me one?
Specially since it was a Google's decision to drop support for its capabilities around Android 7 emulator release.
You can get a system that will run the emulator with great performance for less than $50 on Ebay. There's no possible way to describe or classify this as requiring "Google level budgets for hardware." If you can't afford to upgrade that sucks, but you also can't at all make a reasonable complaint about performance when insisting on using a 10+ year old system.
I have... an idea.
That said - I'd highly recommend checking out the Navigation components that are a part of Jetpack. They make standard navigation patterns, including deep linking, a complete breeze.
It's just frustrating that 10 years later, we still have nothing that is remotely capable of the things an iOS ViewController can do.
It would surely be nice to have the option but a good emulator is needed.
Considering the last patch for just one of the games I play was 50+ Gb, it's pretty reasonable...
https://ziglang.org/download/ https://ziglang.org/#Cross-compiling-is-a-first-class-use-ca...
50 million bytes is really a lot of bytes, it's just that everyone has become accustomed to orders-of-magnitude bloat, and doesn't realize the 100x duplication and inefficiency which sneaks into just about every part of computing where it can get away with it.
For example, with Visual Studio, a large part of the installation footprint are the various SDKs you need to actually build a realistic Windows application (that interacts with the OS, maybe does some COM stuff, brings up a GUI, uses networking..etc) There are also multiple versions of these SDKs, especially the Windows SDKs. Visual Studio also supports a lot of languages, and for some of these languages, there is support going back to very old versions and tech stacks. You can still build Windows XP compatible applications in modern Visual Studio versions.
Can Zig talk to COM? Can it set up a DXGI swap chain? Can I pop up notification toasts as simple as calling one function? How do you package Zig apps for the Microsoft Store?
So yes, you can compile Zig programs for multiple platforms, and these can run on those platforms. But once you start getting into actually interacting with those platforms, you will need all those things you call convenience and junk. Libc is just a fraction of what you need to make applications for a platform.
2. Good to see Google focus on animations finally
3. The CPU profiler looks amazing
The transition to androidx has been slow and painful. But overall Android dev experience is improving consistently
There's a reason we hated Flash-based Web sites, and animation was a huge part of it.
Now I'm considering which is worse: animated UI, or transparent UI. The asinine transparent-UI fad largely and deservedly died in the '00s, with the exception of Apple suddenly jumping on its discredited and defunct bandwagon years later.
Don't see why we need to bring back animated UI either, but I'm happy to consider suggested uses.
Speaking of stacked hierarchies, the rotatable 3-D display of views in a UI might be pretty useful. I like that idea.
With coded constraints you need to do that change code / restart cycle, especially with more complex layouts and SwiftUI isn’t there yet.
Those motion guides look like what Flash used to have, dearly missed.
Compose (Android's swift UI counterpart) also needs to be compiled to see how your change fare.
Even with its preview feature, you need to compile your Compose tree to see how your change look.
This new lib gets a lot of things right, but this one part is a big step back.
Sure, HTML 5 can do everything Flash can do but there is nothing even close to that envioronment for making interactive animation and full games.
That’s interesting, how common is it to write C++ for Android applications, and with Android Studio? I’m not that informed regarding android stuff but I understood that the native development kit wasn’t really that well maintained, making C++ an 2nd class citizen when compared to Java (and maybe Kotlin?).
I would guess it’s mostly used for games?
My one other work-related Android app also used C++, for computer vision-related stuff, 8 years ago. Android Studio/Kotlin/C++ is in my very subjective opinion about 20% better than 2012 Eclipse/Java/C++.
If I wanted to do basically everything in C++, I would strongly consider Qt.
When I tried it about 5 years ago, I ended up dropping Qt and doing Java/C++, because the effort to call Java from Qt wasn't worthwhile.
For example Facebook's Litho is a Java API, and uses a large chunk of the Android SDK's systems. But it also uses a layout engine in C++. This hybrid approach isn't uncommon, and Android Studio has some nice features to work in this mode like being able to follow usages across the JNI boundary and to auto-generate the JNI stubs.
Naturally via this mechanism you can also write portable business code that is exposed via Java bindings library.
Or you invert the logic, and the application is written as a library, with Java/Kotlin just doing the OS connection points and having the NDK logic somehow driving application.
Vulkan and real time audio are also only available via the NDK, to use them from Java/Kotlin you need to write your own bindings.
If you can boot an entire operating system with a single html file, THAT would be impressive.
Eg for "I'd rather not pretend I'll implement data loading from an array or db into a scroll view better than someone else" that'd be the Paging library: https://developer.android.com/topic/libraries/architecture/p...
At least skimming the docs and watching the introduction videos, it does sounds like JetPack might be what I'm looking for! Thanks
The current version of jslinux is wasm, but the original was just a few JavaScript files and could easily have been a single HTML file.
As a bonus, all the tools to debug it (even with a device simulator or remotely on a real Android device) are already installed as part of the browser, and the browser itself is a download of less than 100 MB.
The is the classic web vs native debate. What are we optimizing for? Making it as easy as possible for someone with no experience to throw something together? Sure, the web is great for that. I would rather prioritize performance and the user experience.
The cool thing about the browser is that you don't need other tools. In a sense, the browser has a build step - when the root html file is loaded, it's sub resources are loaded as late as possible, and combined! If you really need more control over this "build" process, you can acquire programmatic control using XHR. What's even cooler is that you can dig into at ANY browser program at runtime! Can you do that on Android or iOS without specialized tools?
The second issue is around the abstractions used to make apps - I'll speak for Android here but I believe iOS is quite similar in outline. In Android, abstractions are incredibly leaky and require you to understand much more about the internal workings than HTML does. I can build a site in HTML without worrying about how the browser implements the functionality - for example, I can make an un-numbered list, or create a list box and populate it with items, fairly easily, even doing so dynamically from JavaScript.
In contrast, on Android, you need to start understanding ListView versus RecyclerView (apparently the latter is better to use?). Then to understand Adapters. Then to figure out how to get content into that ContentAdapter. At some point invariably you'll discover issues with whether your code is running on the UI thread (and blocking the UI from updating while it runs, which is obviously bad), or running off the UI thread (and thus unable to update the UI elements)... You can't (at least in my experience) just get down to focusing on your business logic, without reinventing the wheel a fair bit here. You'll also need to discover the "de-facto go-to library" sometimes, where the built in API isn't good. Bluetooth springs to mind, where I believe most people would recommend using a third party library rather than the included one. That's a discoverability challenge.
I don't think we should take this level of control away from anyone wanting it, but I think it's important we recognise mobile development seems to favour the approach of "bring your own batteries, soldering iron, and flux, as we don't provide any", whereas web has some available batteries and equipment you are free to use, or alternatively to build your own. It would be nice to see some default "batteries" pre-installed, so people can get started without having to learn the details of all the leaky abstractions needed to understand how to get an app to show up and respond to input etc.
And then you have to write all the serialization and back-end support on the server side, or use yet another flavor-of-the-week stack to broker all of the back-and-forth.
I think it will come down to the level of abstraction that works and makes sense, while helping enable building things, though still focusing on the business logic, not the boilerplate.
I guess this is still one of the many un-solved problems!
FWIW, this exact same issue comes up in web development, only it is harder to spawn threads (in this case, web workers) to solve issues.
With Android, you'll probably need to be using UI and non-UI thread work for anything that makes a network request or does more than a "hello world".
And honestly, I'd prefer that an IDE generate a Hello World app with all the random stuff in it that a full-blown app would need, even if it isn't required for Hello World. It makes the learning experience a lot more useful.
If I wanted to poke around with some hobby projects, where would be the best place to start from scratch with all the best practices and development tools?
read the kotlin koans (assuming you are not familiar with kotlin), they are the best way to get used to that language if you know java, and kotlin is much more pleasant to use than java
Best practices and tools might be harder, a LOT has changed in the past 7 years.
Maybe https://github.com/ZacSweers/CatchUp as a sample ?
After that, it depends whether your hobby is to write an android app, or if the resulting product is hobby.
if it is the former, Compose is lots of fun and will be a big leap in android development. You can already use the dev version.
MVI has also deeply changed how I code Android apps. Again, maybe not needed for the level of complexity of an hobby app unless you want to toy with something different.
It does sound very familiar ! Yeah there is nothing new there (and MVI on Android having been heavily influenced by what's going on on other platforms is readily acknowledged).
It is newish (it has been there for several years now) as far as "trendy" Android architecture patterns go.
We started with a bad implementation of MVC for several reasons :
- what Google ended with (which does not look like it fits what they initially intended, but I digress) with its god Activities has encouraged the community to go in that direction.
- when Android was first released, the smartphones of the time were heavily CPU and memory constrained. The way applications were built was to best fit these constraints (sometimes in naive ways).
And again, I am not advocating for all problems to use MVI or that it is the one architecture to rule them all. Just something interesting that was very likely not in gp mind 7 years ago.
so you have
- the state, only containing pure java/kotlin objects)
- reducers to handle state changes. Basically a reducer is a method that takes a state as input (and often another parameter, like e.g. an user input) and creates another state as output.
- and a model of your ui, that is created from each state.
This works very well to have fully testable business logic (which is where the no Android objects is nice, so tests can just run on the JVM) and think about how both state and view changes (both state and view states are immutable, and are altered by copy).
Again, not necessarily something I say that grandparent absolutely needs, but if they want to try something new, it is there.
Meanwhile in the real world, https://jdk.java.net/14/release-notes
You just need to go checking every now and then the gerrit AOSP checkins, they cherry pick stuff from OpenJDK, every version gets a little piece.
Then they use this half baked support to sell Kotlin versus Java, and cleverly never compare Kotlin to the actual Java versions.
Of course in hindsight buying Sun would have been better for Google.
What about go-lang and dart?
Dart is not popular.
From my point of view, Google chose not to buy Sun because they hoped that Sun would just burn to the ground and as such, they would get away with the way they approached the whole situation.
On the other hand if Google had bought Sun, we would still most likely be stuck with Java 6 and just runtime improvements, if at all. If Go and Dart are any examples to go for.
There was no way of knowing the farmer who'd buy the cow would claim goat milk infringes cow-milk protein IP (apologies for stretching the metaphor beyond breaking)
It isn't even as if they don't have their own languages.
C++, Dart, Go, just pick one and provide a migration path.
Don't sell Java compatibility and promise that even with #KotlinFirst, Java and C++ are still relevant for Android. As they did at Google IO 2019.
I'm probably ignorant here. I haven't coded in Java for 5+ years.
People like to talk and bash Oracle, but no one else, including Google bothered with Sun assets, and the community on their own would never made the improvements that Oracle has made in the last 15 years, if the way of Python and Ruby are any indication of how runtime improvements get made.
What I really wanted with regards to that feature was a textbuffer that can accept arbitrary fragments and translate those to Kotlin without committing anything to disk. But it has been a few years, I should check back on that
Modern versions are not as bad (to me) you can use val for type inferring. If irc they are implementing stuff similar to scala.
It's used quite a lot in enterprise as well.
Note: by no means I'm a Java dev, I learnt to hate it a little less.
Maybe data classes? That's not a game changer to me.
Coroutines? Loom will be better.
Nullable references? This might be worth it, but in my experience Optional<T> is enough.
And you get all that even if you have to target old JVM versions for some reason.
Check out inline functions and reified generics, too.
There's some compelling stuff there.
Regardless in kotlin you can simply do:
val s: String? = null
return s as String
val s: String? = null
!!s.trim()
What you're arguing is a false equivalence. In practice null safety isn't a problem when developing in Kotlin while it is a big problem in Java.
Valhalla has now been coming since 2014, so I would not expect it to help any software project in the next two years or so.
Experimental builds are available.
And when they become available, Java will have them on day one, while Kotlin who knows, specially when it needs to stay compatible with ART.
Kotlin designers will have eventually to face the reality that they are either an Android only language, or that Kotlin multi-platform will need to differentiate between what is supported on JVM and ART.
Surely using nullable annotations is more typing than ! or ?, but that is about it, no need to change languages.
> Surely using nullable annotations is more typing than ! or ?
That's Java's answer to many things but it seriously hurts readability (among other things).
I don't want to scroll over pages of getters and setters with annotations. Simple and common things should be expressible succinctly.
> but that is about it, no need to change languages.
Null safety is such basic need that it needs to be part of a modern high level language.
Not everything needs getters and setters, it is just cargo cult generating them blindly.
Also Java has records now, but you aren't going to get them on Android anytime soon.
Static analysis like PMD is also a basic need, not using something like Sonar as part of a CI/CD is just being careless.
> Not everything needs getters and setters, it is just cargo cult generating them blindly.
JavaBean spec (with getters and setters) is actual standard. It's purely theoretical argument that you don't have to use them while in reality they are used always and everywhere and any PR without them would be shot down immediately.
Setters/getters are just one example of Java's boilerplateness.
> Static analysis like PMD is also a basic need, not using something like Sonar as part of a CI/CD is just being careless.
Yes, but I want that feedback during coding and not in CI/CD. Yeah, I can set it up in IDE, but that's more configuration, more things to break up, more team wide standards. Why not just use Kotlin?
I'm no Java hater, I code Java for most of the day professionally. But why pretend that it's perfect? It's 25 years old with unfixable mistakes built in and ripe for replacement.
Sounds like a strict "your company" problem. No one needs to use the JavaBeans spec. It's fully optional.
> Yes, but I want that feedback during coding and not in CI/CD. Yeah, I can set it up in IDE, but that's more configuration, more things to break up, more team wide standards. Why not just use Kotlin?
You make a very weak case here for Kotlin since you need a static analyzer anyway (e.g. Detekt).
> I'm no Java hater, I code Java for most of the day professionally. But why pretend that it's perfect? It's 25 years old with unfixable mistakes built in and ripe for replacement.
No one pretends Java is perfect. For many projects I like using Kotlin. But there's also substantial investment in Java and "I have to type a bit less" is usually not enough to justify using Kotlin.
Your company - maybe I've been working in the wrong companies in the past 15 years, because Java's setters and getters have been used everywhere. Also look into some open source projects - how often do you see direct access to (non-final, non-package private) instance variables? Can't really recall a single case. For a good reason - exposing field access on a public interface violates encapsulation.
> You make a very weak case here for Kotlin since you need a static analyzer anyway (e.g. Detekt).
Of course static analyzer is necessary. That does not invalidate the claim that null safety guaranteed by a compiler is much faster/more effective.
> "I have to type a bit less" is usually not enough to justify using Kotlin.
Type less is a small price in typical large scale project. The big win is better readability since you don't have to scroll over tons of boilerplate or artificial abstractions caused by Java's rigidness.
Besides that NPEs are still happening in production all over the world so something is obviously "not ideal".
That's why it should not be called Java at all. Sun sued Microsoft for J++ because their implementation was incomplete. Google got away with that. Java is more than language and few classes from the standard library.
Language spec has very limited set of packages generally in java.lang. https://docs.oracle.com/javase/specs/jls/se14/html/index.htm...
Platform API is here https://docs.oracle.com/javase/10/docs/api/overview-summary....
As now everyone will rush to copyright "common" API signatures, and lawsuit troll anyone found in violation of the copyright?
"I see your FOSS uses `parse(string)`. We own the copyright on that API, please buy a license or we'll sue."
So then every API would become i.e. `umvi_parse(string)` to avoid paying. I'm sure all sorts of auto-prefixer tools would pop up to help automate this, but still...
The Oracle argument (and as things currently stand in their case, the accepted argument) is basically that the API taken as a whole can be protected even if each individual function name can't, so you could protect the "Java API" but not "compare(a, b)". The idea of copyright arising from "structure, sequence and organization" is well established in the computing context as well as others (for example, you can hold copyright in a compilation even if the individual things being compiled aren't themselves copyrightable).
Still, API copyright would lead to all sorts of uncertainty at least at first, and certainly puts compatible implementations or reimplementations in the crosshairs, so I'd really prefer an Oracle loss here.
And let's be honest, that does make some sense. We've all designed APIs that were particularly elegant and that we were proud of as something almost artistically beautiful. Surely APIs as a whole can constitute some kind of intellectual property.
I'm not sure if copyright is the right way to protect APIs, mostly because copyright lasts for an absolute eternity in software engineering timeframes. But I do think that there ought to be some protection against others copying an API (unless you license it e.g. as open-source), although interfacing with an API should always be allowed.
For example, would I be able to create an airplane with the same cockpit layout (same button/lever positionings, etc) as Boeing so that pilots don't have to learn a completely different layout to fly Umvi brand planes?
The whole programming landscape would need to be audited.
You just them as free beer, because a couple of developers have decided to put their money for you, specially the ISO ones.
A number of industry professionals have also made this argument. See Eugene Spafford's amicus brief for an example: http://www.supremecourt.gov/DocketPDF/18/18-956/133474/20200...
By copying Java's APIs in a non-interoperable way, Google has diluted the Java ecosystem and sown confusion amongst users of the language, thus diminished the value of the IP held by Oracle, and Oracle is entitled to damages.
Writing in Kotlin really is a nicer experience and with near full access to all the legacy java libraries I would never want to switch back even with the small improvements java has made to be more like Kotlin. I highly suspect as the number of java devs that are exposed to Kotlin increases the number of devs happy to write in Java over Kotlin (or Scala) will decrease. Android going Kotlin first was in part justified by giving the decision makers a short period of a week or two to get adjusted away from java and see how they felt about the language in comparison
Most of the code was already written in Java. So I just used the tool to convert to Kotlin. Then I tried to infer how Kotlin works based on the generated code to write the rest. I don't feel proud about that project.
Good to know for my next Udemy course.
Google could just run OpenJDK on phones and toss all the garbage they built, but they're too proud. The GC and performance of ART isn't anywhere near OpenJDK
In the community one of the easiest ways to spot if an example is old and probably out dated is if the author wrote it in Java. New things people aren't even bother keeping up the guise that Java is relevant to new things.
Also Kotlin isn't created by Google and I personally would rather see Kotlin come out on top if we are directly comparing it to Swift.
Also I wasn’t referring specifically to Android, where I realize Kotlin is now dominant.
Then what are you referring to? The only languages Google has released are Dart & Go, which are 8 & 10 years old respectively. That doesn't remotely qualify as "farting out new languages every few months"
In terms of Android features Android Studio is more than just the android plugins, but if you like the latter then go for it?
Nevertheless, Gradle is currently much more popular than Bazel for Android development so it makes sense that this is where the focus is.
Also I noticed that the final 3.x minor release was much faster on my Mac than any of the others before it. I hope 4.0 keeps or improves the performance.
Most likely they are using one of/combination of: After Effects, Premiere Pro, DaVinci Resolve, iMovie and/or Final Cut Pro as those are the more standard tools in the industry.
Then again, I just started using it. So far I'm pleasantly surprised at its UI. After using the detestable UI in GIMP (and the somewhat hokey-looking one in Audacity), I didn't expect much from open source.
Because it has a nice video editor in it, that's useful for lots of things.
Might be hard to get into if you never used Blender before. But if you've done 3D modelling in Blender, you'll be pleasantly surprised that your intuition of how to move, scale and generally edit stuff works the same in the video editor as in the rest of Blender.
https://developer.android.com/studio/run/emulator-accelerati...
(Edit: On Linux, KVM for AMD should work already; this advice is for Windows hosts only)