Transcript
Humble: I'm Charles Humble. I'm an independent technology consultant and also managing editor for Conissaunce consultancy firm, Container Solutions.
I'd like to start by asking the panelists if they could briefly introduce themselves, and maybe also tell us what drew you all personally to come and work with or on the Java platform?
Ritter: I'm Simon Ritter. I'm the Deputy CTO at Azul Systems. When did I start Java? Way back in 1996 when I joined Sun Microsystems. Originally, I didn't join to do Java, I joined to do Solaris the operating system. Very shortly after that, it became clear that Java was going to be something quite big. I figured I'd probably follow that. I did follow it all the way through the Sun years. It got acquired by Oracle and spent five years there. Then for the last five and a half years, I've been at Azul basically doing the same thing for a long time, which is just to promote the Java platform and help people understand how to use it.
Gee: I'm Trisha. I am the lead Java advocate at JetBrains. For a long time, I was the only Java advocate at JetBrains. I tend to do a lot of telling people what's new in Java, what's great about Java. Showing them inside IntelliJ IDEA, of course. My focus is more on Java the language and Java the platform. I have been doing Java since I was at university. It was Java 1.1. I've been doing Java for a long time. I was a Java developer in a range of different companies for 10-plus years. Then I worked at a company called LMAX, which is a financial platform in London. There, we were doing loads of cool stuff with pair programming and with open source stuff. I got involved with the London Java community. It was then that I realized that I didn't just want to be a Java programmer, I wanted to take everything that I learned working with LMAX working in the London Java community user group, and help other people coming behind me as well, so share a lot of Java knowledge, which is how I ended up becoming a developer advocate. Because I was like, there's this job where I can tell people cool stuff that I've learned about Java. I've been doing this at JetBrains for six years now. That's the longest I've ever worked anywhere.
Pressler: I'm Ron Pressler. I'm technical lead for OpenJDK Project Loom at Oracle. I've been working with Java on and off for almost 20 years. What drew me to work on Java on the OpenJDK was the sheer technological achievement of it. If you're interested in compilation or garbage collection, or low-overhead profiling, then OpenJDK is the place to be. It's state of the art.
Jiang: I'm Emily Jiang from IBM. I'm the Liberty Cloud Native Architect and also advocate. I work on the open source project MicroProfile, under Jakarta, basically design the specifications for doing Java based cloud native applications. I got involved in Java since 1999. I think I self-taught myself with Java, and also, I learned in the University. Then, when I worked for IBM, 14 years ago, I just only worked with Java.
Java's Popularity
Humble: Last year, we celebrated 25 years of Java. What do you think it is that's kept Java so vibrant and popular for all this time?
Ritter: It's a number of things, obviously. I think the initial design of the language was very practical. If you ask James Gosling, he's always described it as a blue collar language. It was designed to get the job done. It wasn't a research project. It was very much about getting things done. That obviously appealed to people a lot. I think the real power of Java the platform is the JVM. As Ron said, the OpenJDK project is where it's at, because there's lots of really cool stuff going on there. I think the fact that it has continued to evolve in such a way, over those 25 years, and we've seen more things being added to it, and it's just become a more powerful platform. It just appeals to people. The fact that it can scale up to internet type of sizes, that's what's really keeping it there.
Jiang: I think the other aspect of Java is because it's so easy to use. Also, it has a very rich ecosystem like when microservice was introduced, and then people said, "No, we need to go and invent a different programming language." Then eventually people went to Go, and went to other languages, and a lot of people came back to Java. It's because, yes, some languages are powerful. However, once it goes wrong, you don't know or have no idea what's wrong. Then, Java has a lot of tooling and support. The Java Community evolved really fast. Basically, the community is vibrant. Basically, the Java developers are trying to help each other out, and then invent new APIs to do the job.
Gee: I think Simon alluded to this as well. The backwards compatibility is really important for enterprise type organizations as well. They're probably less excited about a language which is evolving and going places and more excited about a language which does the job and isn't going to break, allows them to just get stuff done and get stuff done well. Even if you upgrade to the newer versions, backwards compatibility is there. The other thing is that particularly now you have all this momentum with the Java community, you have a lot of Java developers. If you want to create a project, you're going to be able to hire people to support, Java is a very appealing thing, because you got a whole bunch of Java programmers who can come on board. They have the community support. They have the library and framework support. Java has a good backwards compatibility. The JVM is powerful. You can run other JVM languages on top of it. What's not to like about a platform like that?
Pressler: I think that over the years, the reasons for Java's popularity have changed. These days it is mostly recognized as a serious platform for serious software. Like Trisha said, it's dependable. It offers an unparalleled combination of performance, productivity, and observability. Meaning monitoring and profiling. If you have an application that would need to last for many years, and be maintained by a large team, and needs very good performance and good runtime insight, Java is the obvious choice.
Role of Stewardship in the Success of a Language
Humble: How important do you think the role of stewardship is in terms of the success of a language? We've talked about backwards compatibility and we've talked about the role of the community. How about the role of stewardship?
Pressler: I think it's very important. The stewards tend to get much of the flak. People need to remember that there's only a very small group of stewards, and millions of them. It's a very tough job, almost thankless, I would say. The stewards of the language and the platform in general need to consider not just whether or not something is useful. People say, "I want this feature. It's useful." Oftentimes, they're right. It's not just about whether something is useful or not, but whether it carries its weight. Like, does the utility justify a change of this magnitude? Is this something that we see ourselves maintaining for the next 20 years? Making those decisions is hard, and that's the core of stewardship.
Ritter: I'd agree with that. I think that Oracle and the people that Ron alludes to, so Brian Goetz, John Rose, Mike Reinhold, do a fantastic job of actually keeping Java in the right direction. It is a thankless task. It is very difficult to judge, should we add this feature? Because, yes, lots of people will like that feature. Some people will not like that feature, and go back and forth on it. There can be a lot of discussion about it. Certainly, if we go back four or five years, in terms of how Java has evolved especially with the new release cadence, we've seen some really nice new features, but introduced in it in a very positive way. I think the benefit of things like preview features, and the incubator modules has really demonstrated that by allowing fully formed features to be added to the language or the APIs, let people try them out and give feedback. Then potentially include changes on that before it becomes part of the standard, I think really is helping Java to remain popular and to continue in that direction.
Gee: Another thing that's interesting and unique about Java is the fact that you have OpenJDK, which is open source, although there are obviously various processes around getting involved with that. You've got the JCP, and you've got the stewardship side of stuff. You have this unique combination of inputs into the language, which I think helps do things like maintain the standards, suggest things that might push the language forwards. You have the stewards suggesting maybe which direction that should go in. I think, at the moment, the way the language is going, that tension I think is a good thing. You have people like Azul who are able to commit stuff to OpenJDK. It's not all just down to Oracle to move the language forward. That's a positive thing.
Jiang: I think what Trisha said is absolutely true. I think with Java, with the stewardship and with Oracle's leadership; also, it's open source, basically is to encourage other companies to participate. Also, ask feedback from end users and get some input. I think these are all very important to keep Java vibrant and move along to the right direction.
Java's Comparison to Functional Programming, Non-Blocking IO, and its Learning Curve
Humble: Where do you think Java is right now compared to other languages in terms of functional programming, non-blocking IO, and learning curve?
Pressler: Java is not a functional language. It doesn't want to be a functional language. It does, like many other languages, some particular aspects of functional programming. In fact, it's interesting, over the years since Java 1 until today, the biggest features that came to the Java language have come to Java from ML, a language called ML. First, we have generics and then Lambda expressions. Now we have ordering data types in the form of records and sealed types, and pattern matching. In 2022, Java will be more or less on par with ML that came out in 1973. That is largely intentional, because even though we like many of the ideas, programming is also about what people are accustomed to. It's also a matter of fashion. When fashion moves, languages move with it. Non-blocking IO? That's Project Loom. I think Java has a very compelling story there. Learning curve, compared to what? It's very hard to say. Maybe Python is easier to learn. C++ and Rust are definitely harder. Haskell is harder. Scala is harder. Go is about the same. Yes, so a good place in the middle, I think.
Gee: I'd like to comment on the learning curve side of stuff. I talk to a lot of developers, particularly developers who are new to Java, or are returning to Java from another language. There is criticism around the amount of boilerplate required to get started. You have to have a whole class and you have to have public static void main. Honestly, it's a bit of a pain in the neck, but once you get used to that everything else is fairly straightforward. Obviously, I'm going to start saying that IDEs are a good way to learn Java as well because I work with IntelliJ IDEA, but IDEs really do help. Particularly, I work with other developer advocates doing other languages, and with something like Java, which is so easy for the IDE to help you with, because it's got all these beautiful type safety, and the compiler will tell you a bunch of stuff. The IDE can say, do you want one of these? Do you want to do this? Can I generate you one of those? There is a bit more boilerplate in Java, for example, than in some other languages, although it has been going away a lot over the last few releases.
I think that using the right tools, like perhaps an IDE or a learning platform, Java can be a very approachable language to learn how to program well. If you're writing JavaScript or something, of course, you can write it straightaway, but does it do what you expect? Because you don't get your compiler errors, you don't get useful immediate feedback. Of course, I'm not trying to dis JavaScript too, because there's a huge JavaScript ecosystem out there, and it's very helpful. A lot of that is huge and moving very fast. Java is moving much faster than it was, but it has a little bit more of this stability, which makes it a bit less intimidating to learn, what's the right thing to learn now? I think for learning curve, Java is a very appealing language. I think that we haven't really told that story very well lately. I think people get put off by having to have too many lines of code in their public static void main method, and then leave it there, which is a bit sad.
Jiang: The other thing for the learning curve, I think that Java is moving quite fast. However, like when Java 16 was out, and very soon you got YouTube videos from IDEs, like Trisha yourself. Also, the developer advocates create videos to show how to use these features. I think it's very easy to get up to date with the new Java features. I think you just need to find the right channel.
Ritter: I agree with everything that everybody's already said. The interesting point about the functional side of things, as Ron said, it's not a functional language. I remember that when I was at university, I did one course on Lisp. I very quickly realized that my mind didn't work in a functional way. I could do procedural languages, but I couldn't do functional languages. It just didn't click with me. What I have found is that with the introduction of Lambda expressions, and the streams API in JDK 8, that was, again, off to Brian Goetz and the people who did that. It was a really good way of introducing a functional style of programming into an object oriented language and making it approachable so that people could use it.
From a learning curve point of view, I think that Java is a great language in terms of getting started. Again, as Trisha said, using the IDE to really help you and figure out what's going on, and to get started type thing. You can very quickly become productive with Java, but there are a lot of things to learn, little details that you need to pick up on. The learning curve is ok, but then you've got to keep going. Again, as Emily said, there's lots of stuff out there. We have a great ecosystem. We have many people who are producing videos and articles. The access to information in a free form is just incredible for Java.
The Path Forward For Ahead Of Time Compilation
Humble: Do any of you have any remarks about the path forward for ahead of time compilation? It seems like a good way to solve things like cold startup for serverless FaaS for the recent JEP, that would be 410, suggesting the community is backing away from this, or at least not maintaining a standard implementation for it. Is that right? What are people's thoughts on that?
Ritter: AOT versus JIT is always going to be an interesting discussion. It really depends on what you're trying to do. A lot of people look at microservices, and they think microservices, if you take it to the extreme you go serverless computing, where you want essentially a function that's going to start up, do something, and then shut down. Then, yes, speed of startup is absolutely critical to that. Resources are going to be critical as well. Anything that's going to be running for any length of time, what you want overall is going to be better performance. If you do pure AOT, then you're not going to get as good performance, especially with Java than you will with JIT, reason being that JIT can do things like speculative optimizations, it can do much more aggressive method inlining than you can get with static compilation. Yes, you can do profile guided optimization, that's been around for a long time, but it's still not going to be as good as being able to compile the code as you're actually seeing it run. It's a balance of, do you really want fast startup or do you want faster code when it's actually running and warmed up, as to why that's happening?
Pressler: I think there's a misunderstanding about JEP 410, which is not about AOT in general, it's about a particular feature and that particular implementation of that feature, and that particular feature doesn't do AOT that well. To emphasize what Simon's just said, you want AOT if one thing is most important to you over everything else, and that is fast startup. I think people are excited about AOT, maybe thinking it does other things. If startup is the one and only and most important thing to you, that is when you want AOT. If it isn't, you probably don't want it as much as you think. Before you try to do AOT, there are other solutions that can reduce startup time significantly, not nearly as much as AOT, but still, I would recommend looking at AppCDS, Application Class Data Sharing, and jlink. They go nicely together. If you are interested in AOT, then actually the community is thinking about it in the form of Project Leyden. I don't know how long it's going to take, when, and stuff like that. I think people need to think more about when they actually want it and how important it is. It might be addressed but it's probably not a major requirement. Various people will say it's not top priority.
Ritter: Because I work for Azul, we have Zing JVM, and we have some technology which is called ReadyNow, which essentially takes a profile of a running application when it has warmed up, and then you can reuse that to reduce the startup warm-up time on an application when you restart it.
Adoption of the Latest Java Version
Humble: There are a couple of variations on this question. One from Tarik, for instance, which has to do with adoption, which is a notoriously difficult thing to measure. Certainly, some of the research I did when I was prepping for this panel, that looks like Java 8 is still the most widely used version, about three-quarters of developers in the various areas I looked at seem to be using Java 8, and then about a quarter on Java 11. What would you say to Java developers who are stuck on Java 8 and perhaps trying to encourage them to move, and/or to their managers to try and encourage them to move to a later version?
Gee: Of course, the answer is, it depends. I can see that the question says, "Other than records, new features, potential security, and performance." Those are the things I was going to say. The new features are great. Performance is better, and security is going to be better. The thing is, of course, it depends, like you say, who you're going to sell it to. If you have to sell it to your management, they obviously don't care about records. They don't care about using VAR. They don't care about your syntactic sugar. For the developers, the features are really interesting. I've been using a lot of the features that have been coming in ever since 8. We're working on a Spring Boot application at the moment, the developer advocates are using Java 16. It's nice to be able to use records. They just work. It's great. It's nice to be able to use VAR when you don't want to put all the stuff in there. Middle management doesn't care about that. I feel like they should care a lot more about performance and security.
A lot of those things can boil down to cost savings, actual money savings. Because obviously if you're running faster, if you're using fewer resources and you're running in the cloud, doesn't that correspond to money saving? Plus also, when you're talking about hiring and recruitment and stuff like that, if you're using more recent versions of Java, that's appealing too. There's also to some extent the recruitment story. Of course, it's a bit of a chicken and egg thing there, because if most developers are currently using Java 8, they might not feel comfortable going to a job where they're using a recent version where they don't know what the new features are. There's definitely appetite amongst the developers that I've been speaking to, to be working on at least Java 11, would be quite nice, and preferably 17 when it comes out.
Jiang: The other thing is even though you don't use Java 16 features like records, then if you move from 8 to 16, and you still get garbage collection or the optimization, all these performance and security fixes, these are one thing. The second thing is, maybe the company attrition rates are low because people are allowed to use new shiny stuff and get developers engaged. They feel like they know all the modern technology, their job is secure. The third thing is, although Java 16 is not LTS, however, once you move to 16, then when 17 is out it's straightforward to move to 17. You don't have a big shock, "My application doesn't work at all." You are completely stalled.
Ritter: I think in terms of adoption, I wonder if that three-quarters is actually correct. There's several surveys on this. I know when I was doing in-person conferences, which was over a year ago, asking people in the audience which version of Java they were using, and that was a year ago, I found there was actually more adoption of JDK 11, not then JDK 8, but more than a quarter. I think that that has gradually shifted as well, over time. I think more people are making that jump now. There is a little bit more work going from 8 to 11, than maybe from 7 to 8. It's not that great. I think that people are potentially thinking it is more work than it is. When they actually make that switch, they realize, actually, it's not as difficult as we thought, and off they go. Once you've made that switch into the module system, then everything becomes very easy after that, because moving to 12, 13, 14, and so on, there aren't really any issues in terms of backwards compatibility. It becomes a lot easier there. I think the move from 11 to 17 is going to be very straightforward.
Pressler: First of all, I agree with Simon. The numbers I have say about 60% and dropping on 8. I expect that by the end of the year, the majority will be on 9 plus. The main reason to switch is money. Unless you're a company that doesn't care about money, you can stay on 8. If you do care, I suggest you move because you're losing money every day on 8. You're just wasting on hardware and support. The cost that you'll save by upgrading will almost surely dwarf the cost of the transition itself very quickly. Simon mentioned the module system. At first, many people have to do the 8 to post-9, 11 in many cases, transition, which is the last ever major Java release. Java 9 was the last major Java release, since then we've just had minor releases. That is a big one.
It had various changes that caused difficulties, and it had the module system, but the two are not related. The difficulties that people see, less than 1% are related to the module system. They just know that the module system is the big feature so they say everything is because of the module system. That is not why. The main reason is that the ecosystem ossified around Java 8, and people used many libraries, relied on internal implementation details. Those internal implementation details just changed. There were more of those in 8 than previous releases, more libraries that did that. Just when we tried to change anything, then many libraries broke. Since then they fixed and that is why it's much easier to upgrade now than it was two years ago. Of course, I hope that we'll see most people on 9 plus by the end of the year. Many of them will probably be on an old version with an LTS service, so I'd say 11, part of it. Most of those is probably by mistake. LTS I think is mostly good for legacy applications that don't see much development. We'll take care of that. First, let's get everyone over the hump of 8 to 9, and then we'll clear up the confusion around LTS.
Gee: I wanted to jump in with another thought that follows on from that, which is that we seem to be constantly telling the story of, how do we sell people on upgrading? I feel like perhaps us, as developers, should just do it. I have just done it on a bunch of open source projects and just swapped out Java 8 for Java 11, and it sometimes often just works. That's how you could sell it to management. It worked. There's nothing wrong. It's running in CI. I've got my integration tests running, nothing fell over. I didn't have to make any fixes. Let's just do it. Especially, like you said, Ron, there was a lot of noise and a lot of confusion around 9, but if you're using a modern version of Maven, or Gradle, if you're using modern versions of the libraries that will have taken care of a large number of the problems that were happening around about the time that 9 came out.
Java Features to Use or Avoid
Humble: Is there anything you would advise people to stop doing with Java either on the JVM or using a JVM language or the Java language itself, or anything which is not used much that you would perhaps recommend people to use more often? Maybe there are particular tools that have been added to the JDK recently that you feel developers maybe don't know about or which are underutilized.
Ritter: The one thing I'm going to tell people to stop using, applets. Just stop it. I did a quick Twitter poll on this because I wanted to see if anybody is actually still developing applets or using applets. I think the majority of people either never developed an applet, or they had done it in the last century. I think one person joked that they were actually currently developing one out of some couple hundred responses that I got. Yes, if there's one thing in Java you want to stop using is applets.
Gee: I don't think I have like one thing in Java I would tell people to stop using. I'm going to come a little bit back to the IDE because to me coding is all about the experience inside the IDE, but I'm always in Java. Stop typing out all your code. Stop typing it. The IDE is going to help you. It's going to generate stuff. Listen to those suggestions that the IDE says, for example, pre-Java 8, you're doing an anonymous inner class, would you like to turn it to a Lambda? Just do it. See what the code looks like. Use the IDE to help you learn the new language features. Use the IDE to remove code that's not being used, or that's not quite read. I know that's not really what the question was asking, but my experience with Java developers is the idea that the language should fix everything. We have responsibility as developers to be like, let's try and get rid of some of the crap that we're writing in our code.
Pressler: I would say, maybe stop trying to look for the JRE, it is gone. It's an outdated mode of distributing Java applications. Use jlink and bundle a custom runtime. You don't need to use to modularize your app to do it, just run the jlink command. It's very easy and you get your own custom runtime, which is very small, can be as little as 30 megabytes. It runs great. It's very convenient. It's a great way to deploy Java applications.
Jiang: The other thing is the things that you don't want to use in Java, you should keep an eye on all the JEPs, like all the features that have been deprecated, or to be removed. You need to react faster, like to avoid using it, to avoid the huge migration headaches in the early days.
The Future of Reactive Programming
Humble: Reactive programming is a style of programming that allows us to make better use of high throughput servers. Obviously, it's become fairly popular in the last three or four years. Since we've got Ron here, I was curious to know, with Project Loom, if you think that reactive programming is something that you would expect us to continue doing or whether you think it will be superseded?
Pressler: The short answer is no. I expect people to use it less. These asynchronous frameworks were designed to address very real need, high throughput service that handle a large number of concurrent requests. These requirements simply cannot be met with the old thread per request model that hangs on to an OS thread for the entire duration of a transaction. While those libraries make the code more or less tolerable, provided that your entire application is written in that style, the all or nothing, and it's not bad that they had to be this way, but they still fundamentally clash with the design of the Java platform and its tooling. Debugging and profiling applications written in that style is very hard. Most people don't like using. They enjoy using them unless they have to. Project Loom will hopefully make the old thread per request model scale as well as the asynchronous style. Not only you do not have to redesign an application for that, technical requirements with large number of concurrent requests, but everything is going to be harmonious with the platform and the tooling that is still very much designed around threads. Those who genuinely enjoy asynchronous style will probably continue using it. Everyone else won't have to, to get that same scalability and performance.
Jiang: I think Project Loom helped with asynchronous programming. Dealing with all the new thread creation and utilize all the resources. However, we still need to have a higher level messaging, when you create a reactive system, or this application, basically, then you link with Kafka and you link with MQ. I think this system stills needs a high level API. However, underneath it may be able to benefit Project Loom, for the resource management. That's why in MicroProfile, we still have the MicroProfile reactive messaging, and to be able to do reactive messaging architecture.
Humble: Simon, Trisha, anything you want to add?
Ritter: Not really from my point of view. I think Ron said it all, which is that Project Loom is the answer to this. I think that's going to be a great way of making life a lot easier for people, so they don't have to take a different approach to the programming style. I'm very much looking forward to Project Loom being integrated into the OpenJDK mainstream.
Relationship between Java and Other Languages
Humble: What do you think the relationship should be between Java and other languages like Kotlin and so on, in the future? Are they incubators for new ideas? Are they for specific niches? Are they competition to Java? How do you see that working?
Gee: I'd like to take that from the Kotlin side, although I don't actually work that closely with the Kotlin team. JetBrains is still very heavily involved with Kotlin development, even though that's also an open source language, so we're not the only people developing on it now. Java evolving the way it has, especially in terms of borrowing and sometimes adapting some of the features from languages like Kotlin does encourage the language developers of Kotlin to keep moving that forward as well. Because if Java is going to continue to release every six months and release with nice, interesting features that other developers like, then a language like Kotlin is going to have to continue to have something which differentiates it from the old fashioned, slow Java type paradigm.
Similarly, Kotlin, when they're introducing new features, like they have VAR and Val, and like Java has final VAR, because it does. When Kotlin introduces these new features, Java gets to look at Kotlin and go, "That's useful and helpful in Java," or, "Actually, we can't really get that to work that well within the Java community." I really do see it being as a little bit of an arms race, but a mostly symbiotic relationship, because both languages get to borrow features from each other if they seem to work. Kotlin has a number of different platforms. It can compile down to a bunch of places. It's not always just JVM language. Kotlin gets to benefit from the improvements on the JVM. Kotlin is not always a full on competitor to Java, as long as Java is improving its performance and its security. I feel like Loom is potentially going to benefit Kotlin as well. I don't really know how but I feel like it could. As long as Java is evolving, it also benefits these other languages too. I really do feel like this is a symbiotic, helpful relationship between the JVM languages: Java the language and the JVM platform.
Pressler: I don't think Java has borrowed a single feature from Kotlin to date. It might in the future get nullability types. That would be maybe the first one. The language that we're trying to borrow ideas from is ML, except we're still up to ML 1973. That's where we're aiming, so generics, Lambda expressions, records, sealed types, and pattern matching, and then will more or less be ML 1973. After that, we'll see. VAR and Val, that's also 1973, from ML. One day we might get to the point where we're trying to borrow features from Kotlin, and other languages, but different languages have different design philosophies. Java's design philosophy, from very early on, wants to be a very conservative language. That platform needs to be very innovative, but the language should be conservative.
It seems like a great test. While there is a great new people who enjoy faster moving languages, it seems like most people don't. It's great that the Java platforms offers a choice for everyone. Languages like Clojure, and Kotlin, and Scala are certainly faster moving and more innovative, and Java is intentionally conservative. Depending on whichever one you like, then the design of the platform helps them work together. One of the things that people sometimes complain about when it comes to the Java platform is generic type ratio. The one thing that makes all those languages work together is generic type ratio. If Java had built its own particular variant strategy into the runtime, then those languages could not have interoperated, as well as they do. It is thanks to type ratio, that we get all those languages working together.
Ritter: One of the things I'm going to have to have a conversation with Ron about at some point is, at what point do we call Java, ML? Why hasn't ML been so popular? I think the other thing is that clearly the Highlander principle doesn't apply here, as in, there cannot be only one. The whole idea of having multiple languages that have different approaches to how they deliver programmability is the important thing. Really, the critical bit is the fact that they can all compile into bytecode, so they can run on top of the JVM and they can take advantage of the performance that you get from the JVM, and the manageability, and all that sort of thing. I think that's the key thing there. Obviously, again, as Ron said, there is this idea of looking around and seeing what other languages do, primarily ML. We have, I believe, borrowed one thing from Python, which was the multi-line strings, because that had the three double quotes. If I remember rightly, that was Python that had that. I think that it's healthy to have a look at what other people are doing and think, how can we use that?
Jiang: This is very true. I think we should encourage multiple languages. Then with the computation, they learn from each other, and then encourage other languages to run faster. Again, they are all JVM languages, so that community can work together to improve the JVM. This is great.
Keeping Java Relevant For the Next 25 Years
Humble: What is one thing that you'd like to see happening to help keep Java relevant for the next 25 years?
Jiang: Java should keep on moving. Don't stop. Keep the current pace.
Ritter: I'd agree with that very strongly. I think the whole six-month release cycle has been a fantastic move for Java to keep it fresh and keep it moving with bringing new features in more quickly. I think that's one of the key things. We've got to keep that pace up.
Pressler: Personally, speaking only for myself, I would love to see more focus on the small things. I said at the beginning that Java is the platform of choice for serious software. I think it should be also attractive for less serious software, because that's where most programmers start. We've had some nice changes in that space, most notably JShell, which is REP of Java, and the Java source file launcher that lets you directly run a single source file without separately compiling it. We need to see more. I would love to see a basic build tool that's part of OpenJDK.
Gee: I agree with all of that. I'm going to go on a slight tangent rather than talk about Java, the language. I think the thing which can continue to make Java relevant and attractive and a great platform going forward is the community, the user groups, the libraries, the framework, the fact that we share so much for free. The fact that there's a whole bunch of blog posts, videos, the Foojay thing that Azul is working on. All of these things are just great resources to get developers started, to get them up and running. We've been working on this Spring Boot application as a team who is not very familiar with the technology, and all of the tutorials and blog posts and videos out there help us to get up and running really quickly. Even if there were a lull in the releases, even if there was something which stalled the language for a while, like we had between maybe 6 and 8, the language will continue to be relevant if the community continues to be relevant and active.
See more presentations with transcripts
