17 comments

  • einrealist0 minutes ago
    I have been using Java since version 1.4. Both the language and its ecosystem have come a long way since then. I endured the height of the EJB phase. I adopted Spring when version 1.2 was released. I spent hours fighting with IDEs to run OSGi bundles. I hated building UIs with Swing/AWT, many of which are still in use today and are gradually being replaced by lovely JavaFX. When I look at code I wrote around 12 years ago, I'm amazed at how much I've matured too.
  • dzonga2 hours ago
    the people that work on Java &amp; the JVM are very smart.<p>it has become a best of breed language - hell its better than Go for industry purposes.<p>the drawback with Java will always be the CULTURE - (maybe someone can insert a quote of how in physics progress is only made, when old physicist die - I don&#x27;t wanna be morbid ) but with Java same that&#x27;s when the culture will change.<p>All those people using typescript (could be using Java - but the culture doesn&#x27;t want them and consider them heretics for not embracing religion of OOP and FactoryFactory)
    • lucketone1 hour ago
      &gt; for not embracing religion of OOP and FactoryFactory<p>Not the case today. Of course, crappy code (or questionable patterns) can be found in all languages, and java community had made some innovations in the area early on, but today we have a different picture.<p>FactoryFactory has gone mostly extinct, the most likely place to see it is “dailywtf.com”.<p>We now know that we prefer composition over inheritance, we have stream api - language and community evolved, old patterns are not neccessary anymore to solve same&#x2F;similar problems.<p>Sample of one - junit (testing lib) source code, from quick glance it seems more procedural than dogmatic OOP: <a href="https:&#x2F;&#x2F;github.com&#x2F;junit-team&#x2F;junit-framework&#x2F;blob&#x2F;main&#x2F;junit-jupiter-api&#x2F;src&#x2F;main&#x2F;java&#x2F;org&#x2F;junit&#x2F;jupiter&#x2F;api&#x2F;AssertArrayEquals.java#L434" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;junit-team&#x2F;junit-framework&#x2F;blob&#x2F;main&#x2F;juni...</a>
    • stanac1 hour ago
      After ~13 years of working with C#, I moved to Kotlin. It&#x27;s such a beautiful language. When I have to read docs for a Java lib I realize why I like Kotlin.<p>I want to say culture around Java doesn&#x27;t have to change, new culture is growing around succinctness (if not simplicity) of Kotlin, and it gets most of the benefits of Java ecosystem.
    • mands1 hour ago
      It&#x27;s getting better, it doesn&#x27;t all have to be Spring Boot and JBoss.<p>There is quarkus, helidon and micronaut for slimmer more modern backend frameworks. jbang for scripting (think uvx, bunx), Tambo UI (<a href="https:&#x2F;&#x2F;tamboui.dev&#x2F;" rel="nofollow">https:&#x2F;&#x2F;tamboui.dev&#x2F;</a>) for terminal UIs, and more.<p>Along with all the new Java features that help you write much simpler code - eg. virtual threads, structured concurrency, stream gatherers, and performance &#x2F; resource improvements.<p>It&#x27;s not all there yet, but I think the next few years things will come together nicely (however a better build system is sorely needed - one of the things that Go &#x2F; Rust did right).
      • cess111 hour ago
        If someone reads this and wonders what JBoss is, the contemporary variety is called WildFly and it is actually rather easy to install and play around with.<p><a href="https:&#x2F;&#x2F;www.wildfly.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.wildfly.org&#x2F;</a><p>I think this is an often overlooked solution to some of the problems we nowadays tend to approach the clown for.<p>As for build systems, Maven is old and cranky but if something else replaces it, it will probably be quite similar anyway.
        • zokier14 minutes ago
          &gt; As for build systems, Maven is old and cranky but if something else replaces it, it will probably be quite similar anyway.<p>Bazel is the most obvious contender and very different from Maven in almost every possible way.
    • pjmlp15 minutes ago
      Enterprise space architecture is not picky, all programming languages get a place when they manage to hit big at corporate life.<p>It can be Yourdon with C and Pascal, Booch with Smalltalk and C++, Patterns with Smalltalk and C++, UML with Ada, C++, Smalltalk and Java, Rational RUP , Java and .NET application servers, Kubernetes with WebAssembly microservices,....<p>Ever looked into Typescript with effects, pretending to be Haskell?
    • refulgentis1 minute ago
      Front page, 82 comments, comment 2 hours ago…why is this the top comment? “People who write Typescript could just be writing Java except they’re scared of being outcasts for not using design patterns” is bait, not a serious technical opinion.<p>Oh. That’s why it’s the top comment.
    • HendrikHensen1 hour ago
      What do you mean by &quot;better than Go for industry purposes&quot;?<p>I don&#x27;t understand what &quot;industry purposes&quot; means and in what aspects Java is better than Go in your opinion (I can think of some myself, but I&#x27;m interested in your perspective).
      • kyrra1 hour ago
        Not the GP, but for really large code bases, Go is missing a few features that I&#x27;ve noticed:<p>1) No immutable types. My work team is a huge user of immutable data stuctures in Java to make sure data passed around to other teams isn&#x27;t changed. Go doesn&#x27;t really have a good way to do this.<p>2) Refactoring can be really annoying (or at least really noisy) because of public&#x2F;private being defined by capitalization of method&#x2F;field names.<p>3) Error handling isn&#x27;t great. I love Go&#x27;s errors being just normal values, but the `error` interface is awkward when trying to figure out what kind of errors can be thrown without having in-depth knowledge of the kinds of errors that can be returned. We regularly need to make different decisions depending on the kind of error returned. Knowing which errors can be returned in Go is not defined by the method being called (only in comments).
      • nradov57 minutes ago
        Ya, that seems to be a misunderstanding. &quot;Industry purposes&quot; covers a huge range of stuff. Go is pretty good for systems programming where Java isn&#x27;t really an option due to the fundamental limits imposed by garbage collection and lack of pointers. Java is pretty good for higher-level application development where occasional GC pauses are tolerable (the GC pauses are rare and fast now, but they still rule out using Java for certain purposes).
        • zokier12 minutes ago
          Go has gc too and arguably worse one than Java
    • andyjohnson01 hour ago
      &quot;a solid foundation for the future&quot; is faint praise for a language that has been around for over thirty years.<p>&gt; It has become a best of breed language<p>To me it lags significantly behind .net (runtime) and C#&#x2F;F# (language). I don&#x27;t see Java catching-up.
      • gf0001 hour ago
        They trade blows, and have different philosophies (complex runtime, simpler language vs the reverse).<p>E.g. on the GC side Java is ahead of any other platform, especially with the low-latency ZGC garbage collector.
        • spockz1 hour ago
          I would love to have a Java compiler with the capabilities of the .net compiler. To make incremental builds to aid code completion including type information, looking past simple syntactical errors, fixing them, and continuing compilation.<p>Currently, this is “magic” embedded in eclipse, IntelliJ, and maybe a bit in the vscode plugin. Imagine having a Java LSP running that can provide all this information while typing.<p>.net has had this for ages. From a language design I think that is wonderful.
          • hocuspocus18 minutes ago
            Java LSP backends are basically headless Eclipse and NetBeans, they definitely go beyond syntactical errors.<p>There&#x27;s also the upcoming Metals v2 that&#x27;s using another compiler frontend optimized for performance, Google Turbine: <a href="https:&#x2F;&#x2F;metals-lsp.org" rel="nofollow">https:&#x2F;&#x2F;metals-lsp.org</a><p>Actionable diagnostics for Java aren&#x27;t implemented yet though.
      • lucketone1 hour ago
        Java is 4th on tiobe.<p>Bright future for it just means it is not planning to become 40th or 400th.<p>(My prediction - in next ten years java will always be among top 6; new language might come to the very top and some leapfrogging game between c# and java)
    • karel-3d2 hours ago
      I didn&#x27;t use Java since 7, but from people that do - nowadays you basically don&#x27;t code Java, you code Spring Boot. And that has all the bad things you think when people say &quot;Java&quot;.<p>I don&#x27;t know if it&#x27;s true though.
      • gf0001 hour ago
        There are more Java devs than people in my home country. Like how could you even give a single description for all of them? They all work on vastly different stuff, from low-latency trading to robotics, to regular old CRUD. Not even the CRUD part is as monotonic though as you make it out to be.
      • ivan_gammel1 hour ago
        Spring Boot isn‘t bad. It‘s opinionated about configurations and dependencies. Its main advantage is that you can start shipping production-quality code very quickly, focusing on business problems rather than anything else. Vibe coding on it is more or less stable, entire apps can be built solo in a few months. And it‘s easy to do fullstack with SSR based on Thymeleaf and Htmx. It is absolutely superior to anything that exists for node stack.<p>And then there‘s also Micronaut, if you prefer compile-time setup to Spring.
      • ezfe2 hours ago
        There&#x27;s a lot of programming that has nothing to do with SpringBoot - and I say this as someone who works in a backend team that uses SpringBoot for all our apps.
      • shermantanktop1 hour ago
        You&#x27;re talking to specific people.<p>A completely different culture of Java usage can and does exist a lot of places. It is absolutely true that success creates a certain ossification of practice. But SpringBoot is not necessary, any more than Guice or any other framework-y thing.
    • moralestapia1 hour ago
      I am captivated by your thought process.
    • Arwill1 hour ago
      Once i heard a manager explain &quot;we must get rid of anything Oracle, including Java, because of license reasons&quot;. I see this attitude everywhere since.<p>JavaScript people are too afraid to use Java, that is why something like TypeScript exists.<p>And for personal projects, C# has become a better and more fun &quot;just works&quot; platform.
  • ludovicianul1 hour ago
    I program in Java for more than 15 years now. I can resonate with people hating the language from it&#x27;s early days due to the experience with all the enterprisy features and over abstractions. Or confunding Java with the Spring ecosystem. But Java came a long way over the years. It&#x27;s now what many would call a &quot;modern&quot; language. It&#x27;s less verbose, has many of the features people find appealing in Scala and Kotlin and it can even compile to native binaries using GraalVM. This made building CLIs in Java feasible. Or lambdas.
  • vyskocilm2 hours ago
    JEP 504: Remove the Applet API<p>Glad to see this being removed. Java plugins especially on Linux were awful and required by tons of corporate stuff. Anyone remeber IcedTea Web? A functional and opensource Java plugin and Java Webstart implementation?
    • anthony8825 minutes ago
      Note that the the Java plugin and webstart was removed a long time ago.<p>I personally regret that the API was removed as it&#x27;s a few classes and they are still used. Just search JApplet on Github. It&#x27;s also possible to run applets in the modern browsers with WASM or in Java IDE&#x27;s as plugin.
    • hju22_-32 hours ago
      Remember IcedTea Web? Oh boy, I still have environments that use it.
    • cyberax2 hours ago
      I made several Webstart corporate apps back in the day! The infrastructure was pretty neat, when it worked. And it was a whole lot better than JS back then, still in the IE6 times.
      • vyskocilm31 minutes ago
        Yeah XMLHttpRequest and activex thing IE6 had. That was Javascript style that days.
  • haolez3 hours ago
    I was pretty surprised when I learned recently that the Java alternative for green threads doesn&#x27;t use colored functions. It put Java in a higher place in my perception.
    • zokier2 minutes ago
      [delayed]
    • dxxvi1 hour ago
      No need of colored functions because that Java green thread returns a Future&lt;Value&gt; not Value like colored functions
    • dmos622 hours ago
      What are colored functions?
      • cogman102 hours ago
        Any time you have a barrier between one function being able to call another. The original article on this called them red functions and green functions. A green function can call a red function but a red function can&#x27;t call a green function.<p>In terms of async, it&#x27;s when you have to have a function with &quot;async&quot; attached to it and making it so that only other async functions can call async functions.<p>It ends up creating a weird circumstance where you can end up with a lot of duplicated APIs, particularly in libraries, because you are providing both async and non-async versions of functions.
      • AlotOfReading2 hours ago
        The term comes from an old blog post [0] about different kinds of effect systems. Every function has a color, and every colored function can only call functions that are compatible with it, usually of the same color. The net result is that you end up either duplicating a lot of your common code so you have compatible interfaces for all the different colors (let&#x27;s call that &quot;separate but equal&quot; if we&#x27;re feeling spicy), or you end up shoving round pegs into the square holes of your dominant function color.<p>[0] <a href="https:&#x2F;&#x2F;journal.stuffwithstuff.com&#x2F;2015&#x2F;02&#x2F;01&#x2F;what-color-is-your-function&#x2F;" rel="nofollow">https:&#x2F;&#x2F;journal.stuffwithstuff.com&#x2F;2015&#x2F;02&#x2F;01&#x2F;what-color-is-...</a>
      • ihumanable2 hours ago
        <a href="https:&#x2F;&#x2F;journal.stuffwithstuff.com&#x2F;2015&#x2F;02&#x2F;01&#x2F;what-color-is-your-function&#x2F;" rel="nofollow">https:&#x2F;&#x2F;journal.stuffwithstuff.com&#x2F;2015&#x2F;02&#x2F;01&#x2F;what-color-is-...</a><p>The terminology is used to talk about languages that have async and sync functions where you declare (or color) the function as either async or sync.<p>In these languages it&#x27;s pretty common for the language to enforce a constraint that async functions can only call other async functions. Javascript &#x2F; Typescript, Python are popular examples of languages with colored functions.
      • jauco2 hours ago
        <a href="https:&#x2F;&#x2F;journal.stuffwithstuff.com&#x2F;2015&#x2F;02&#x2F;01&#x2F;what-color-is-your-function&#x2F;" rel="nofollow">https:&#x2F;&#x2F;journal.stuffwithstuff.com&#x2F;2015&#x2F;02&#x2F;01&#x2F;what-color-is-...</a><p>In this context: functions anotated with async
      • saltyoldman2 hours ago
        [flagged]
      • Starlevel0042 hours ago
        [flagged]
        • antonvs2 hours ago
          No, it refers to a function that has constraints on how it can be called and composed. A classic example is functions tagged `async` in languages like Javascript or Rust.<p>(Technically, that&#x27;s the symptom - the underlying cause is that it&#x27;s a function that involves some effect, like asynchronicity, or, in some functional languages, IO.)
        • izacus2 hours ago
          No.
    • Groxx2 hours ago
      &quot;green threads&quot; is generally how I see these systems identify as &quot;non-colored but with async-like performance&quot; fwiw. or &quot;fibers&quot;. otherwise it&#x27;s &quot;async&quot; or &quot;coroutines&quot;.
      • wahern1 hour ago
        There are different types of coroutines. The C++ type are sometimes called &quot;stackless coroutines&quot;. With stackless coroutines you can&#x27;t yield from a nested function call. Stackless coroutines are basically generators where you can pass arguments through resume, and async&#x2F;await is effectively a form of stackless coroutines with yield&#x2F;resume semantics that aren&#x27;t fully generalized as coroutines, but oriented toward some bespoke notion of concurrency rather than as an abstract control flow operator.<p>&quot;Stackful coroutines&quot; allow yielding from any arbitrary point. They&#x27;re basically fibers, except with the explicit control transfer and value passing yield and resume operators; there&#x27;s no hidden or implicit control transfer like with green threads. Though, some people would argue allowing any function to yield without announcing this in their type signature is tantamount to hidden control transfer. Personally, I don&#x27;t see how that&#x27;s different than allowing any function to call other functions, or to loop, but in any event languages are free to layer on additional typing constraints--constraints that can be tailored to the desired typing semantics, rather than dictated by implementation details.<p>Stackless coroutines are typically implemented as a special kind of function whose state is allocated and instantiated by the caller. In contrast, stackful coroutines are typically implemented by reifying the stack, similar to threads. The &quot;stack&quot; may or not be the same as the system&#x27;s ABI stack.<p>In stackful coroutines, unless there are additional typing constraints imposed by the language for hygiene reasons, any function can typically be called as a coroutine or use yield and resume. There&#x27;s no need to compile functions into special alternative forms as call frame management works the same whether invoked from a coroutine context or not.
    • antonvs2 hours ago
      Are you perhaps confusing green threads with stackless async models, like async&#x2F;await? Green threads don&#x27;t imply colored functions.
      • jayd161 hour ago
        They said &quot;Java alternative for green threads&quot; so they&#x27;re talking about <i>not</i> green threads.
        • antonvs58 minutes ago
          What alternative would they be referring to? Green threads were only (re-)introduced to Java in version 21 in 2023.<p>I think what they&#x27;re trying to say is that Java&#x27;s green thread implementation has special support for async I&#x2F;O. Threads that block on I&#x2F;O aren&#x27;t polled for completion by the runtime, instead they use OS async features under the hood.<p>This allows Java&#x27;s green threads to compete performance-wise with async&#x2F;await solutions, but with cleaner code that doesn&#x27;t need colored functions.<p>In older green thread implementations in other languages, I&#x2F;O can actually cause significant CPU overhead due to polling threads that are blocked by I&#x2F;O requests.
  • Bnjoroge1 hour ago
    Man I still have scars learning Java in college. Took the entire fun out of coding until I ended up learning C.
  • freedomben2 hours ago
    As someone who has been out of the Java world for many years, but recently forced back into it due to Android dev requirements, Post lawsuit, what is the relationship between Android (Google) and Java now? When can we expect 26 on Android? On that note, why is Android always so far behind? Is it because Kotlin is primary or is it deeper? Did the lawsuit play a role?
    • gf0002 hours ago
      Java&#x27;s primary development happens on OpenJDK.<p>Android has their own runtime (creatively named as Android runtime), which does <i>not</i> run java byte code, but their own binary format. JVM class files can be compiled to that format, but the support for that always lags behind OpenJDK java versions.<p>Part of the reason kotlin became the de facto language on the platform was that they supported only terribly old Java at the time, that didn&#x27;t even have lambdas even though it was already out.<p>The problem is that most of the Java libraries want to follow the desktop&#x2F;server, aka the OpenJDK scene, but that would make them incompatible with Android so there was&#x2F;is some incentives to bump up the version they support.
    • whynotmaybe1 hour ago
      I&#x27;ve used Java decades ago (anyone remember servlet?) and I&#x27;m glad that I can use flutter for Android development.
  • xeubie2 hours ago
    I think astronomers could measure the age of the universe in nano-Valhallas. Every year, it feels 50% closer to completion...<p>In all seriousness I&#x27;m happy with what Mr. Goetz and the team have done. Sealed interfaces (java 17) + exhaustive switch statements (java 21) means we now have union types in java! And instead of jumping on the async&#x2F;await bandwagon we now have a more general solution that doesn&#x27;t lead to API duplication (virtual threads). But Valhalla has been a veeery long time coming.
    • noelwelsh2 hours ago
      &#x27;Tis true. At the same time, Project Valhalla will be the most significant change to the JVM in a very long time, and probably its best chance to stay relevant in the future.
  • GTP24 minutes ago
    I haven&#x27;t read a Java manual since the time of Java 8. Do you have any books or other resources you could recommend to catch up with all that has changed in these years?
  • olivia-banks1 hour ago
    Really glad to see we&#x27;re getting a native PEM API.
    • lucketone53 minutes ago
      Pleasantly surprised.<p>But it is a preview though.
  • jesse_dot_id1 hour ago
    Cool. I feel as though I&#x27;ll never be able to escape 8, or ignore Ellison&#x27;s legacy, unfortunately.
    • MeetingsBrowser1 hour ago
      &gt; or ignore Ellison&#x27;s legacy, unfortunately.<p>Can you elaborate?
  • oystersareyum1 hour ago
    Do changes to Java itself impact e.g. Clojure? I think it uses many java primitives instead of emitting jvm byte code but I can be wrong.
    • jillesvangurp1 minute ago
      Some of the standard library stuff could be usable from Clojure and other languages. The jvm level optimizations (garbage collection) should benefit all jvm languages. The language changes are mostly not that relevant unless you program directly in Java.<p>I use Kotlin myself (after doing Java since 1995). Most of the overview here reads like they are adding a lot of stuff that Kotlin has had for many years. Structured concurrency, lazy stuff, etc. You can argue about which language does it better&#x2F;nicer&#x2F;etc. but that debate is a bit boring to me. But good for Java developers that they are getting some obviously useful things that so far they never had. Progress is nice. Better late than never.
    • lucketone43 minutes ago
      In general, some java language changes do involve JVM changes.<p>So yes, it impacts other jvm languages like Closure.<p>Here most obvious would be GC improvements.
  • rusakov-field1 hour ago
    Ah , Java, a language I pray I never have to ever touch again.
  • badgersnake2 hours ago
    Vector API (Eleventh Incubator) - maybe 11th time’s the charm.
    • mjuarez2 hours ago
      When it was about the 7th incubator iteration, I got curious so I read the actual JEP history, and it had this informative tidbit, also included in the latest release:<p>&quot;The Vector API will incubate until necessary features of Project Valhalla become available as preview features. At that time, we will adapt the Vector API and its implementation to use them and then promote the Vector API from incubation to preview.&quot;<p>Project Valhalla has been &quot;in progress&quot; for at least a decade now (Wikipedia say 2014). So who knows when we&#x27;ll actually see a Vector API in preview.
      • gf0002 hours ago
        On the other hand, there is a bunch of movement on Valhalla side nowadays. You can download a build and try out value types yourself!
  • AgentMarket1 hour ago
    [flagged]
  • dxxvi1 hour ago
    Does the Java team use AI? If not, they should use it to give us more features and better performance in a release.
    • albusdumbledor349 minutes ago
      Dont you have parents to tell them that? Open a pr in the codebase
  • wiseowise3 hours ago
    Android as always in shambles. Shame that neither Google, nor ecosystem cares about Java because they’ve bought JetBrains kopium.
    • pjmlp3 hours ago
      Google basically played a J++ with Android Java, with Kotlin as their .NET&#x2F;C#.<p>At least they are forced to partially update Android Java, now Java 17 subset, so that Kotlin can keep up with was is mostly deployed at Maven Central.
      • cogman102 hours ago
        Pretty sure they did a J# ;). But I agree that Kotlin is their C#.<p>The JDK and JVM has advanced so fast while android has been lagging. It&#x27;s pretty frustrating, especially because google has been so slow to pull in changes from later java versions.<p>A part of me wishes that android would just dump their hokey dalvik, ART, and other BS and just use the OpenJDK or a fork of the OpenJDK with whatever special sauce they need. A lot of the project Leyden stuff lends itself nicely to maybe someday being able to run real java on android.<p>Edit: Apparently android is forking OpenJDK, since Android 7.<p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Android_Nougat" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Android_Nougat</a>
        • pjmlp2 hours ago
          J# was the transition product to port J++ into .NET, I am quite sure.<p>Not only I was there on those years, my employer was a MSFT partner that got to test .NET before it was announced to the world, so that we could have our products as part of the announcement event in Portugal.<p>OpenJDK is cherry picked, Google only picks pieces of it, rather than full compatibility.
        • hencq2 hours ago
          J++ predates C#. It was Microsoft&#x27;s version of Java that wasn&#x27;t quite compatible.
          • cogman102 hours ago
            Correct, and J# was a brief transition language to help migrate Visual J++ applications onto the .Net SDK. J++ -&gt; J# -&gt; C# was the evolution.<p>I say J# is a more apt comparison because like Microsoft&#x27;s Java, android has a substantial set of APIs that aren&#x27;t part of the JDK standard. Working on Java vs Anrdoid is practically like working with the JDK vs .Net.
            • pjmlp2 hours ago
              J++ already had those extensions, hence the lawsuit.
        • freedomben2 hours ago
          Do you think it&#x27;s legal reasons, technical reasons, NIH syndrome, or some other reason why Android doesn&#x27;t use OpenJDK?
          • cogman102 hours ago
            A little bit of all of the above.<p>Android&#x27;s usage of Java started right as Sun was being acquired by oracle and right before the jdk was GPLed.<p>... And I&#x27;ll be. Apparently Android is using the OpenJDK since Android 7. [1]<p>[1] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Android_Nougat" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Android_Nougat</a>
            • pjmlp2 hours ago
              It isn&#x27;t, check Gerrit commit history, they only take bits and pieces, plus ART doesn&#x27;t do all bytecode equivalents. Some JVM bytecode don&#x27;t have counterparts in Dex, rather get desugared into multiple instructions.
      • xxs3 hours ago
        That&#x27;s a proper late 90s reference, props!
      • cyberax2 hours ago
        &gt; Google basically played a J++ with Android Java<p>No, they didn&#x27;t. Google happily used regular Java until Oracle played Oracle. Then Google stopped updating the supported Java language version and started diversifying away from Java.
        • pjmlp2 hours ago
          They definitely did not, it was Android Java from day one, and Oracle should have crushed them like Sun did to Microsoft, unfortunately Google was the geek darling of do not evil, thus they got a pass from fanboys.
          • geodel8 minutes ago
            Oracle&#x27;s Java Mobile Edition could&#x27;ve crushed Android. No one stopped them.<p>&gt; Google was the geek darling of do not evil, thus they got a pass from fanboys.<p>Oracle&#x27;s case against Google went all the way up to Supreme Court of US. Oracle did not win anything substantial in courts against Google is not fanboys&#x27; doing.
          • cyberax2 hours ago
            Android was not 100% compatible with Java, but mostly because it had a specialized environment. It did not support things like dynamic bytecode generation, but it faithfully reproduced pretty much everything else that made sense.<p>And yeah, it would have been so much better with Oracle(tm)(r)(c)(fuckyou) running Android with Pure Java(tm)(r)(c)(screwyou) instead. Now with EJB5 and more XML!<p>You might be too young to remember, but SunOracle essentially abandoned the Java language development for more than a decade, until Kotlin provided a very much needed magic kick.<p>Oh, and if you think _Google_ is bad for splitting the Java ecosystem, let me introduce you to J2ME and JavaCard.
            • pjmlp14 minutes ago
              My dear I am programming since 1986, and a Nokia alumni.
    • sulam2 hours ago
      I wouldn’t blame Google for Oracle being a lawnmower.