OpenJDK 15 Reaches GA With Garbage Collector Promotions, Tossing Out Solaris + SPARC

[wswartzendruber]

That's the problem unfortunately. Android developers have to settle on the ancient Java and Kotlin, well it (Kotlin) just had to come in to fragment the overall Android development scene. It has becomes even a challenge to find something on stackoverflow these days because things come up for Kotlin as answers and in my domain I am using Java.

I hope the day Google and Oracle settle, Kotlin will just get killed and everyone will be happy forever ;-)

Kotlin's not going anywhere. If the Kotlin Foundation disbanded, their repos would be forked in 0.687 seconds and the community would take over. Nobody who knows Kotlin voluntarily writes new code in Java.

In any event, Kotlin has a multiplatform facet to it. It's not considered stable yet, but you can use it to target JS and native targets, including macOS and iOS. I believe that Google's ultimate vision is to replace the JVM and keep Kotlin.

[om26er]

I'm just truckin' right along with Java 8 and Kotlin.

That's the problem unfortunately. Android developers have to settle on the ancient Java and Kotlin, well it (Kotlin) just had to come in to fragment the overall Android development scene. It has becomes even a challenge to find something on stackoverflow these days because things come up for Kotlin as answers and in my domain I am using Java.

I hope the day Google and Oracle settle, Kotlin will just get killed and everyone will be happy forever ;-)

[Ironmask]

No, it's about the right way to program. As open source advocates, the very idea of trying to control what others do with our code should be anathema. On Stack Overflow, I did see a questioner ask about trying to hide methods in Python. Everyone began asking him why he'd want to do that. He responded he was worried that someone some day might take one of his base classes, inherit from it, and do something with it he never intended. (Gee, sounds like the concept of open source, right?) He was then chewed out by a major Python contributor for having the hubris to believe that he knew what anyone may or may not need to do with his code for all time.

I've also seen a very OCPD programmer uncharacteristically release a library he wrote (not in Python) as open source. He tried to lock down every class and method he could in his library. When some people on a forum asked him why, he exclaimed "Just because I made the code open source doesn't mean you can do whatever you want with it!"

Ergo... people who need to make things private probably have major personality disorders, are bad people, or spent too much time learning Java.

Finally, I leave you with one of the greatest parodies of all time....

Wikileaks To Leak 5000 Open Source Java Projects With All That Private/Final Bullshit Removed

How long have you been programming? Accessibility modifiers aren't about "controlling" what people do at all, they're annotations for what you should and shouldn't be accessing. If a method is private, that means it does some intermediate works, or otherwise is just some intermediate method that might get removed in the next version of the API as it's not a part of the official API. For example, in one of my classes I have a private hashcode function. If someone used that function, and I removed it, they'd complain about it, when in fact it was never my intention to have that function exposed in the first place, and really I don't even want that function to exist at all, I just need it. And I'm not moving it to it's own library because I want this specific class to be single-file. Thanks to accessibility modifiers, I don't have to worry about this at all. Your argument is like saying guard rails should be illegal because it impedes your right to fall into a vat of toxic waste.
Sure, sometimes developers make things private for no good reason, which is just annoying and often leads to bug reports to make it public, but that's far from common. And you definitely shouldn't argue "well some people make bad mistakes with it so it should be removed" because that argument applies to all computers in general. And cars.

Also, Python is far from a language we should be looking at for design decisions. It's probably the worst language I've ever had the misfortune to use.

[alcalde]

I really hope this is sarcasm.

No, it's about the right way to program. As open source advocates, the very idea of trying to control what others do with our code should be anathema. On Stack Overflow, I did see a questioner ask about trying to hide methods in Python. Everyone began asking him why he'd want to do that. He responded he was worried that someone some day might take one of his base classes, inherit from it, and do something with it he never intended. (Gee, sounds like the concept of open source, right?) He was then chewed out by a major Python contributor for having the hubris to believe that he knew what anyone may or may not need to do with his code for all time.

I've also seen a very OCPD programmer uncharacteristically release a library he wrote (not in Python) as open source. He tried to lock down every class and method he could in his library. When some people on a forum asked him why, he exclaimed "Just because I made the code open source doesn't mean you can do whatever you want with it!"

Ergo... people who need to make things private probably have major personality disorders, are bad people, or spent too much time learning Java.

Finally, I leave you with one of the greatest parodies of all time....

Wikileaks To Leak 5000 Open Source Java Projects With All That Private/Final Bullshit Removed

[Ironmask]

Haven't we all learned from Python that everything should be public and accessible? It's an act of Jobsian hubris to imagine that you know better what anyone will need to do with your class forever and for all time.

https://wiki.c2.com/?MethodsShouldBePublic

I really hope this is sarcasm.

[alcalde]

[QUOTE=frant.hartm;n1207335]

How is these new sealed classes that are in preview any different from classed marked with the final keyword?

You can't mark a base class final, because then you wouldn't be able to create your subclasses. If you don't mark it as final anyone can create a subclass.

So with sealed classes, you can now have a base class with subclasses, which you limit as the author of the base class, but no one else can create another subclass (unless you modify the base class as well).

Haven't we all learned from Python that everything should be public and accessible? It's an act of Jobsian hubris to imagine that you know better what anyone will need to do with your class forever and for all time.

https://wiki.c2.com/?MethodsShouldBePublic

[wswartzendruber]

Yeah, I moved from Java to Kotlin. I don't even write any Java 8 code anymore, just Kotlin. This is when apps for Android.

You can use Kotlin for a lot more than Android. Its standard library has an overhead of 1.5 MB, which is much smaller than Groovy.

[frant.hartm]

[QUOTE=uid313;n1207289]How is these new sealed classes that are in preview any different from classed marked with the final keyword?

You can't mark a base class final, because then you wouldn't be able to create your subclasses. If you don't mark it as final anyone can create a subclass.

So with sealed classes, you can now have a base class with subclasses, which you limit as the author of the base class, but no one else can create another subclass (unless you modify the base class as well).

[uid313]

How is these new sealed classes that are in preview any different from classed marked with the final keyword?

I'm just truckin' right along with Java 8 and Kotlin.

Yeah, I moved from Java to Kotlin. I don't even write any Java 8 code anymore, just Kotlin. This is when apps for Android.

[bug77]

It's a little more complicated than that...start here to dip your toe in the issues: https://www.pscp.tv/javazone/1RDGlNjmjgNxL

I don't care much about going through another presentation.
Being able to mock out the GC should be a part of the default battery of automated tests. And while understand the whole thing isn't as simple as it seems (there are always edge cases and stuff), I feel the implementation took longer than it should have. And they still failed to take care of the CLI switch.