Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Java Sun Microsystems

Java Programming Language Celebrates Its 25th Birthday. What's Next? (infoworld.com) 75

May 23rd marks the 25th anniversary of the day Sun Microsystems introduced Java to the world, notes InfoWorld.

Looking at both the present and the future, they write that currently Java remains popular "with enterprises even as a slew of rival languages, such as Python and Go, now compete for the hearts and minds of software developers." Java continues to rank among the top three programming languages in the most prominent language popularity indexes — Tiobe, RedMonk, and PyPL. Java had enjoyed a five-year stint as the top language in the Tiobe index until this month, when it was overtaken by the C language, thanks perhaps to the combination of C's wide use in medical equipment and the urgency of the COVID-19 pandemic.

Nevertheless, Java represents a huge ecosystem and source of jobs. There were an estimated nine million Java developers worldwide in 2017, according to Oracle. A recent search of jobs site Dice.com found nearly 12,000 Java-related jobs in the USA, compared to roughly 9,000 jobs in JavaScript and 7,600 in Python. Plus, Java has spawned an enormous ecosystem of tools ranging from the Spring Framework to application servers from companies such as IBM, Red Hat, and Oracle to the JavaFX rich media platform.

The developers behind Java — including Oracle and the broader OpenJDK community — have kept the platform moving forward. Released two months ago, Java 14, or Java Development Kit (JDK) 14, added capabilities including switch expressions, to simplify coding, and JDK Flight Recorder (JFR) Event Streaming, for continuous consumption of JFR data. Up next for Java is JDK 15, set to arrive as a production release in September 2020, with capabilities still being lined up for it. So far, the features expected include a preview of sealed classes, which provide more-granular control over code, and records, which provide classes that act as transparent carriers for immutable data. Also under consideration for Java is a plan dubbed Project Leyden, which would address "longterm pain points" in Java including resource footprint, startup time, and performance issues by introducing static images to the platform.

This discussion has been archived. No new comments can be posted.

Java Programming Language Celebrates Its 25th Birthday. What's Next?

Comments Filter:
  • Next? (Score:5, Funny)

    by Anonymous Coward on Saturday May 23, 2020 @07:39PM (#60096580)
    Java is owned by Oracle so would guess a slow death spiral?
    • Re:Next? (Score:5, Insightful)

      by AlanObject ( 3603453 ) on Saturday May 23, 2020 @08:40PM (#60096736)

      What is next is obviously another 25 years of both glib and over-wrought opinion articles about how Java is Dead.

      Usually included is the author's favorite language that will take over Java's position.

      In the meantime -- millions if not billions of lines of new Java code will be written.

    • by Z00L00K ( 682162 )

      The policies Oracle have regarding Java will make some organizations hesitant to use that.

      In many cases too complicated licensing is what slowly kills a technology.

      • At least at the moment you can ignore Oracle all together and go with OpenJDK and use one of the builds made available by other players, like Azul or AdoptOpenJDK. I say "for the moment" because even though the platform is open sourced, Oracle still owns the Java license and the test kit so they could theoretically revoke the right to call OpenJDK "Java" if they wanted to.
  • by jlowery ( 47102 ) on Saturday May 23, 2020 @08:13PM (#60096676)

    In Java, in addition to writing a functional program, you have to build an extensive type system. That's half the work, and yet it's not really programming... it's documentation and runtime error prevention.

    Same thing is going on right now with TypeScript. Are custom types worth the bother? I'm on the fence. For quick and dirty stuff, types get in the way. For more complex applications, types can be very very useful (and also have a very very difficult inheritance chain to follow). Thats why, when programming in Java, you really need an IDE to do the bookkeeping for you.

    (I really liked Groovy, where I could mix and match typed and untyped approaches within the same application. Too bad about all that reflection though.)

    • by phantomfive ( 622387 ) on Saturday May 23, 2020 @08:40PM (#60096740) Journal

      Same thing is going on right now with TypeScript. Are custom types worth the bother?

      Using types will reduce your bugs by 15% [ucl.ac.uk] or maybe even by 38% [reddit.com]. Instead of avoiding types altogether, try to think of ways to make your type system simpler, so it doesn't feel so heavy (btw, if you have a good IDE, creating a new type is as easy as "right-click->create-new-class".)

      The real win for a good type system is in refactoring, though. If the type system is done well, it's like self-documenting code. If the system is done poorly, you can still use a lot of the automatic refactoring tools that are not possible in a dynamic language. Even renaming variables is easier with a type system.

      As for typescript itself, it feels a little kludgy. Eventually we'll all be writing frontend code in the language of our choice, and compiling it to web assembly.

    • by AlanObject ( 3603453 ) on Saturday May 23, 2020 @08:46PM (#60096756)

      Are custom types worth the bother? I'm on the fence.

      Not sure what fence you are on but I'm pretty sure you got a lot of splinters in your crotch.

      The reason for Typescript strong typing is so the IDE can more easily help you write code (auto-completion, type checking, etc) that compiles first try and so the IDE can help you find stuff in imported modules. All while still making the weak typing of Javascript available for when that is an advantage.

      You have to know what you are doing regardless of the language. No language is going to save you from your lack of preparedness for a given project.

    • In Java, in addition to writing a functional program, you have to build an extensive type system. That's half the work, and yet it's not really programming... it's documentation and runtime error prevention.

      Ahh horse hocky. It's no better or worse than C/C++. If you're spending half your time on a type system then either your type system is too complicated, or you're coming from a Javascript background where there are no types.

      • Ahh horse hocky. It's no better or worse than C/C++.

        The type systems in C and C++ are so dramatically different that this sentence doesn't make sense.

        • the type systems in C and C++ are so dramatically different that this sentence doesn't make sense.

          I wasn't comparing type systems, I was comparing the difficulty of the type systems.

    • by Somervillain ( 4719341 ) on Saturday May 23, 2020 @09:11PM (#60096844)

      In Java, in addition to writing a functional program, you have to build an extensive type system. That's half the work, and yet it's not really programming... it's documentation and runtime error prevention.

      Wow!....Documentation is one of the most important facets of professional software development. It feels tedious to build so many classes, trust me...if you succeed at your job, it will be handed off to another team and they will put you on another project, if not promoted to a different role. I work at a large company and love that I can just download the source and easily figure out what is going on. That boilerplate makes the code much more reliable, especially 5 years later when the original author left to create his dream startup or get fired or poached by a better employer, etc. The vast majority of real programming is wiring together existing libraries and documenting business logic and workflow that is unique to your project and employer, almost no one gets paid to create algorithms or whatever you think is "real programming."

      When you're not making money or your team is small enough to fit in a minivan, do whatever you want. If your money is on the line and your project need to last more than 5 years, that documentation is very important as people leave, get promoted, etc. There's a reason Java has been on top longer than any modern language in the business world and that's that culture of documentation, object oriented design and strong typing. It becomes mission critical in real world use as authors move on and projects grow in size and scope. It is definitely less fun, but I have inherited many "fun" projects from idiots in love with their own intelligence and creativity...it was impressive when first demo-ed, but a NIGHTMARE to maintain or make production-grade.

      You may be able to write it twice as fast by skipping documentation or design...but then it will get handed off to anther team to make it production grade and secure and they will spend twice as long fixing your idiosyncrasies and your project would be way farther behind than had you just done it right the first time.

      • I find that boilerplate code tends to grow as the winds of fashion blow. Abstraction is a COST. You don't blindly add costs to your software without the corresponding benefits and analysis. Sadly, people DO just blindly add boilerplate, "because that's how we've always done it".

        Not everything needs to be split into a reusable hierarchy 42 level deep and 16 wide.

        Some things are just small, tight, self-contained, not-used-anywhere-else pieces of logic. I don't need the kinds of extreme boilerplate second-syst

        • by Somervillain ( 4719341 ) on Saturday May 23, 2020 @10:25PM (#60097056)

          Some things are just small, tight, self-contained, not-used-anywhere-else pieces of logic. I don't need the kinds of extreme boilerplate second-system-syndrome that demands every string needing left padding needs a special class hierarchy to handle it. (I point out a piece of stupidity from the JS community here, but Java programmers are among the primary offenders here, regardless of which language they might be in.)

          That's not a Java issue. That is an HR issue. Any useful tool can be misused. If there's too much OOP ceremony, that is bad code, plain and simple. A lot of Java programmers are absolute garbage. A lot overengineer. There's a happy middleground between insane and impractical complexity and "cowboy coding"...which is extremely idiosyncratic code, written quickly, with no documentation, validation, weird structure, etc.

          The best practice is to have the right amount of structure, no more, no less. Most people that complain about Java don't seem to have many years experience or seem like they are working at young startups. I found OOP/Java off-putting at first 22+ years ago when I was used to scripting languages. However, once I handed off code and had code handed off to me, I greatly appreciate it. The JVM is awesome, but so are many platforms. The Java language is good, but not really much better/worse than it's competitors. The reason Java succeeded was a mix of technology and culture that JavaScript, PHP, Go, and Python never replicated...highly documented best practices, near-universal conventions for everything, backward compatibility over language innovation and my favorite is the fact that once compiled everything just runs...decades into the future. If you did it right the first time, it is very low maintenance, even many decades later.

          I have horrible JSF code I wrote 15 years ago which still runs today. I am embarrassed by it (the technology is really dated and the UI is very basic and amateurish now), but the company that paid me got their money's worth. All they do is update the JVM and some libs from time to time. No one has touched the source code in 12 years. It still has 100s of daily users for mission critical clinical data processing. The team that inherited it when they laid off my division like our apps for that reason...they just work...no drama, no fuss, that app may very well outlive me. It's ugly as sin, even for it's day, but it works, has passed lots of security audits from many companies, scales well, and just keeps running. A team that has never met me keeps adding on to it.

        • by Livius ( 318358 )

          Not everything needs to be split into a reusable hierarchy 42 level deep and 16 wide.

          I think that's more a problem of overly-elaborate object-oriented programming. Object-oriented programming is great but it's not a magic bullet and it's not the only way to achieve reuse. When used correctly it actually has significant constraints, which are sometimes clues that a problem really calls for something else like composition.

    • by theJavaMan ( 539177 ) on Saturday May 23, 2020 @09:12PM (#60096850)

      I'm afraid that's incorrect. A type system is exactly programming. Without it, you're not writing code, you're just hoping that what you wrote will run.

      Look into Type Theory. The fundamental concept is that a compiler performs a mathematical proof of correctness of your code. It guarantees mathematically that your program will provide a particular set of outputs given a particular set of inputs. That's huge! With a well structured type system you can eliminate whole classes of errors, making your code unquestionably better.

      • I've heard, on many occasions lately, that we should't even be trying to design or specify our software, because we can't possibly know what we want, and it's all too complex, and people will wants changes, and, and, and....

        The net claim made at the end of these statements is always that thinking through a design first is a waste of time. The proponents of these arguments suggest that you should sit down at your editor, without any clarified intention held in your mind (forget specified on paper), and, as i

        • by swilver ( 617741 ) on Sunday May 24, 2020 @06:01AM (#60097880)

          If you have a language that's strongly typed, then refactoring that code will be much easier because the risk of introducing errors is reduced many fold thanks to the compiler warning you about type mismatches.

          So yes, if you use a strongly typed language with a picky compiler, then just program. Refactor later.

          If not, then either design upfront or redesign the entire app in 3 to 4 years because it is unmaintainable.

        • by Kjella ( 173770 )

          I've heard, on many occasions lately, that we should't even be trying to design or specify our software (...) Well, sure. Blind brute force works for evolution too. It just comes with ridiculous vestigial appendages and insane inside-out-and-upside-down-ass-backwards gotchas, relies on constant breakage, and takes a few million years to produce results of questionable value.

          Sure, but how do mismanaged waterfall projects go? You produce a ton of crap somebody thought was a good idea three years ago when they were scratching their ass trying to come up with a specification full of things it turns out they don't actually want or need, either because it turned out to be stupid in practice or the perceived need has disappeared. Also the progress went to 90% on time because everybody was pressured into keeping the project on track or at least claiming to, but the last 10% will take

        • There is value in implementing a prototype quickly to check whether the implementer and the customer are on the same page regarding what kind of system needs to be built. That doesn't mean formal methods are useless though.

          First, a prototype is not the same as a production system and for important and/or complex systems, it can be worth doing a more formal specification after the prototype is built.

          Second, regardless of what behavior the customer expects from the system, there are a lot of possible behavior

    • by Cobron ( 712518 )
      " For quick and dirty stuff, types get in the way."

      why would you ever want to put something quick and dirty in production?

  • by jblues ( 1703158 ) on Saturday May 23, 2020 @08:15PM (#60096680)
    Kotlin (https://kotlinlang.org/) is a fantastic language for the JVM. It can also target native and compile to JavaScript. On the JVM front it is completely interoperable with standard and open-source Java libraries.
    • I've done some Kotlin now, I agree in a number of ways it's probably better, or at least more modern than Java... has it gotten any traction outside Android though?

        Like would we be seeing EJB (or other enterprise) stuff being developed in Kotlin?

      • by jblues ( 1703158 )

        Yes, but not as much as it deserves. For example, Rod Johnson, founder of Spring (defacto standard enterprise Java framework) raved about Kotlin, called it a game-changer. But it is not like every second Java backend is using Kotlin now. Some places do - Netflix for example.

        So that's backend. Meanwhile it can compile to JavaScript and native. I tried JavaScript, and even though I like the language better than TypeScript, the latter was much easier. Better tooling, community, etc. I haven't tried native yet

    • by swilver ( 617741 )

      It's a nice trail ground for features to be added to Java later.

  • 26th (Score:5, Funny)

    by Lonng_Time_Lurker ( 6285236 ) on Saturday May 23, 2020 @08:29PM (#60096714)

    obviously

  • by Snotnose ( 212196 ) on Saturday May 23, 2020 @08:43PM (#60096748)
    Back in '96/'97 I was lead for a test group that needed to figure out what we were going to use for a framework for our tests. Java had been out for about 6 months at the time. When you started a program it took a good 20-30 seconds for it to start, then it ran just fine. As our tests were going to be a bunch of small tests that ran in 2-3 seconds Java was right out. I ended up using perl as our framework, and we ended up with hundreds of tests, most running in 2-3 seconds.

    6-7 years ago I looked into Java again and I quite like it. That 20-30 second delay starting a program is gone. The language is pretty damned verbose which, as I like 80 column windows, is a bit of a problem. But streams is awesome, it's like *nix pipes in a program. I'm not gonna be writing a device driver in Java, but for everything else I prefer it over C++.
    • My biggest concern with Java is that it requires an insecure runtime...but I guess that's really no different than Python and everything else these days.
    • The startup delay isn't gone, it's just masked by massively more powerful hardware. The overhead is still there, and wasting resources which other options would not.

      • by swilver ( 617741 )

        You are partially right. More powerful hardware helps, and with Java, it will actually run on such hardware even if that hardware didn't exist yet at the time of writing. However there have been substantial wins in reducing overhead, better GC and better compilation.

        Other options however waste a far more precious resource, developer time, usually significantly more at multiple fronts: compiling, programming, debugging.

  • by surfcow ( 169572 ) on Saturday May 23, 2020 @08:44PM (#60096750) Homepage

    Who knows how great Java might have become if Microsoft hadn't forked it?

    • You joke but Microsoft did have their own JVM for a while in the 90's. In the typical Microsoft way, it wasn't fully compatible with Sun's JVM so you either had to target Sun Java or Microsoft Java. Since the Microsoft JVM was part of Internet Explorer this likely hurt Java on the web the most, as it wasn't as simple as "Does this need to run on Windows?" for desktop applications. Sun eventually sued Microsoft over their shenanigans and Microsoft quietly killed off their JVM.

  • 25??? 25 years ago I was still in high sch... no wait... when Java came out I was at uni...

    Thanks for reminding me I'm old

    • The worst part of getting old is watching all the youngsters ignore decades of past experience, only to have to re-learn it the hard way. It's particularly gut-wrenching when an entire industry does it repeatedly (cf. Web 1.0, 2.0, 3.0). The sane people get out at or shortly after the peak of these waves, a whole bunch of new people reinvent all the wheels, and anyone dumb enough to stick around (like me), gets to make the same tired arguements over and over.

  • For those that have not seen them before, here's a good rundown [medium.com] (yeah, it's on Medium... sigh) on what makes switch expressions so much more powerful than the classic Swift construct... this is a feature that has been added to a number of new languages so it's nice to see Java get it.

  • Java Programming Language Celebrates Its 25th Birthday. What's Next?

    Next year it will celebrate its 26th birthday. (That's how calendars and anniversaries work -- right?)

  • by AirHog ( 118412 ) on Saturday May 23, 2020 @10:17PM (#60097036)

    If you haven't heard, Java is heading back to the browser!

    Several tools let your Java code run in modern browsers without plugins or applets. The best-performing tool is TeaVM:

        http://teavm.org/ [teavm.org]

    It powers many large websites, and is the technology behind CodenameOne for the web ( https://www.codenameone.com/ [codenameone.com] ) and SnapKit ( http://reportmill.com/snaptea/ [reportmill.com] ).

    Read more here: https://blogs.oracle.com/javam... [oracle.com]

  • I can finally have 25 years of Java experience and qualify for that job in the late 90's
  • I have a clear memory of going to lunch one today while working at West Tasman, Cisco's new HQ back in the 90's, and the conversation was "hey did you hear there was a team from Sun in visiting today. They've invented a new programming language that they call Java and they were trying to persuade us to re-write IOS in it!". We all laughed. IOS was written in GNU C.
    The irony is that all my (now ex) Cisco colleagues, who still code, are writing network stacks for routers in Java.

  • by Dracos ( 107777 ) on Sunday May 24, 2020 @12:51AM (#60097396)

    Finally learn that Java and Javascript are not the same thing?

  • Everybody using Java to do anything important will hope that it becomes the "new COBOL" in that it essentially never changes and just works for decades. Oracle however wants it not to become that and therefore changes minor things while still not accepting the noteworthy improvements of Java2K.

  • by Plugh ( 27537 )
    Itâ(TM)s the future!
  • I liked Processing's ability to easily do graphics, read the mouse, and read Arduinos, but I detest Wh'Oracle. I don't think that mainsteam Python libraries covered all of those bases. Although it would be akin to a brain-stem replacement, wish that Processing were rewritten in something else than Java. Perhaps a language such a Julia could cover those bases. I don't think that even mainstream Sigh.
  • Kotlin is Java modified by all we've learned in the last 25 years.
    And you can just drop-in Kotlin into existing Java setups.
    I've had multiple people recommend to not even bother getting into Java but use Kotlin right away.
    Seeing the difference I totally get it.

  • "It's a trap!" said commander RMS...
  • Oracle and Java jumped the shark. Nothing to see here. Move along.

Real Programmers don't eat quiche. They eat Twinkies and Szechwan food.

Working...