> Java 8 language support update: APIs you can use regardless of your app’s minimum API level
Meanwhile in the real world, https://jdk.java.net/14/release-notes
Meanwhile in the real world, https://jdk.java.net/14/release-notes
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"
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.