Java Tries a New Way to Use Multithreading: Structured Concurrency (infoworld.com) 96
"Structured concurrency is a new way to use multithreading in Java," reports InfoWorld.
"It allows developers to think about work in logical groups while taking advantage of both traditional and virtual threads." Available in preview in Java 21, structured concurrency is a key aspect of Java's future, so now is a good time to start working with it... Java's thread model makes it a strong contender among concurrent languages, but multithreading has always been inherently tricky. Structured concurrency allows you to use multiple threads with structured programming syntax. In essence, it provides a way to write concurrent software using familiar program flows and constructs. This lets developers focus on the business at hand, instead of the orchestration of threading.
As the JEP for structured concurrency says, "If a task splits into concurrent subtasks then they all return to the same place, namely the task's code block." Virtual threads, now an official feature of Java, create the possibility of cheaply spawning threads to gain concurrent performance. Structured concurrency provides the simple syntax to do so. As a result, Java now has a unique and highly-optimized threading system that is also easy to understand...
Between virtual threads and structured concurrency, Java developers have a compelling new mechanism for breaking up almost any code into concurrent tasks without much overhead... Any time you encounter a bottleneck where many tasks are occurring, you can easily hand them all off to the virtual thread engine, which will find the best way to orchestrate them. The new thread model with structured concurrency also makes it easy to customize and fine-tune this behavior. It will be very interesting to see how developers use these new concurrency capabilities in our applications, frameworks, and servers going forward.
It involves a new class StructuredTaskScope located in the java.util.concurrent library. (InfoWorld points out that "you'll need to use --enable-preview and --source 21 or --source 22 to enable structured concurrency.")
Their reporter shared an example on GitHub, and there's more examples in the Java 21 documentation. "The structured concurrency documentation includes an example of collecting subtask results as they succeed or fail and then returning the results."
"It allows developers to think about work in logical groups while taking advantage of both traditional and virtual threads." Available in preview in Java 21, structured concurrency is a key aspect of Java's future, so now is a good time to start working with it... Java's thread model makes it a strong contender among concurrent languages, but multithreading has always been inherently tricky. Structured concurrency allows you to use multiple threads with structured programming syntax. In essence, it provides a way to write concurrent software using familiar program flows and constructs. This lets developers focus on the business at hand, instead of the orchestration of threading.
As the JEP for structured concurrency says, "If a task splits into concurrent subtasks then they all return to the same place, namely the task's code block." Virtual threads, now an official feature of Java, create the possibility of cheaply spawning threads to gain concurrent performance. Structured concurrency provides the simple syntax to do so. As a result, Java now has a unique and highly-optimized threading system that is also easy to understand...
Between virtual threads and structured concurrency, Java developers have a compelling new mechanism for breaking up almost any code into concurrent tasks without much overhead... Any time you encounter a bottleneck where many tasks are occurring, you can easily hand them all off to the virtual thread engine, which will find the best way to orchestrate them. The new thread model with structured concurrency also makes it easy to customize and fine-tune this behavior. It will be very interesting to see how developers use these new concurrency capabilities in our applications, frameworks, and servers going forward.
It involves a new class StructuredTaskScope located in the java.util.concurrent library. (InfoWorld points out that "you'll need to use --enable-preview and --source 21 or --source 22 to enable structured concurrency.")
Their reporter shared an example on GitHub, and there's more examples in the Java 21 documentation. "The structured concurrency documentation includes an example of collecting subtask results as they succeed or fail and then returning the results."
Huh, looks like Ada tasks (Score:5, Interesting)
Of course, Ada has had concurrency with 'tasks' since 1981, and 40 years of experience implementing language semantics (both compilation/code generation and the runtime environment.) Ada83 had rendezvous for synchronization between tasks. Ada95 added protected objects to make it easier for tasks to avoid stepping on each other. A lot of the work on real-time scheduling (e.g. Rate Monotonic) came from people discussing how to implement Ada83 task scheduling where tasks can have different priorities, with Ada providing a common language to -describe the problem-.
But hey, there's no advantage in computer science for discovering your new shiny problem was addressed 40 years ago...
Re:Huh, looks like Ada tasks (Score:5, Funny)
But hey, there's no advantage in computer science for discovering your new shiny problem was addressed 40 years ago...
Ada would probably run too fast on modern CPUs, hence Java as the alternative.
Re:Huh, looks like Ada tasks (Score:5, Funny)
Ada would probably run too fast on modern CPUs
Just unpush the Turbo button
Re:Huh, looks like Ada tasks (Score:4, Funny)
But hey, there's no advantage in computer science for discovering your new shiny problem was addressed 40 years ago...
Ada would probably run too fast on modern CPUs, hence Java as the alternative.
The 16 people seriously using Ada would probably agree. :-)
[Said as someone who has done some professional Ada development work.]
Re: (Score:2)
> But hey, there's no advantage in computer science for discovering your new shiny problem was addressed 40 years ago...
Why do you think Java devs believe this is a new discovery rather than offering a first-class implementation in their language?
I didn't see that.
Ada has had it ... Java finally gets it ... assholes!?
Re: (Score:2)
Ada has had it ... Java finally gets it ...
I read it that way too and TFA reads along those lines as well.
Re:Huh, looks like Ada tasks (Score:5, Insightful)
From the beginning, Ada83 came with tasking/concurrency, exceptions, and generics (aka templates). Look how long it's taken other languages to catch up, and the implementation problems those languages had working out the details.
This is not to claim Ada83 was perfect. Rather, I claim that other language designers have been negligent for not knowing the body of work in other programming languages, and -not repeating many of the design/specification/implementation problems-. Gluing such features onto languages after their initial specification results in problems that could have and should have been avoided.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
It's a myth that Ada83 was "a language designed by a committee." There was a team, but it was led by Jean Ichbiah, who made the primary decisions. I remember talking to John Barnes, who was on that team, asking "Why does Ada have/not have xxx?" and being told "That's because Jean said so."
The language was complex, but that often produced really simple programs. I remember one example where we implemented TCP in both C and Ada (the SPARK verifiable subset, mostly.) To do the TCP 'timeout' provision, the
Re: (Score:2)
C - the most influential system programming language of all time - preceded Ada by nearly a decade and does not have explicit support for a lot of things as a matter of simplicity. Of course it has other downsides that motivated the creation of languages like Ada.
I don't think you are going to be able to make the case that the inventors of languages like Java and C# were so hopelessly uneducated that they were unfamiliar with work done in languages like Ada though. Java had a concurrency model from the begi
Re: (Score:2)
Java had a concurrency model from the beginning and it was one of the first languages to have an explicit one.
According to Wikipedia, James Gosling, Mike Sheridan, and Patrick Naughton initiated the Java language project in June 1991.
The specification for preliminary Ada (including tasking) was released in 1980. I guess a decade is within the time range for "one of the first."
I remember reading the rationale information from Gosling on Java back in the early '90s, and how he studiously avoided mentioning
Re: (Score:2)
How many commercially significant programming languages with a concurrency model do you think were invented between 1980 and 1991? Erlang is the only major one that I am aware of, although there were certainly a few minor ones. Modula-3 didn't exactly hit the big time.
Re: (Score:2)
Well GP has a point. Java developers do like claim that kind of thing often. And if you prove them wrong, they'll continue denying it. Example: here's a Java developer that fancies himself a teacher of Java:
https://slashdot.org/comments.... [slashdot.org]
Just scanning through TFA, I don't see anything in it that I already know is a thing on C# or Rust. (Though the way they propose sharing data between threads sounds messy, which Java never was averse to. But I'd need to see the implementation before criticizing it. Howeve
Re: (Score:2)
good move with top level functions without needing to fuck with classes in cases where they're totally unnecessary and pointless, something C# introduced 3 years ago.)
And C++ has had from the start.
Re: (Score:1)
A deque is usually a double linked list, with one ling forward and one back ward.
The rest of your post made not much sense to me.
Re: Huh, looks like Ada tasks (Score:2)
Yeah I don't expect you to understand any of that.
Only crappy languages make deque into linkedlist.
Re: (Score:1)
A double linked list is the fastest deque implementation.
And a LANGUAGE has nothing to do with the implementation of data structures.
You can implement any data structure in what ever language you want.
Re: Huh, looks like Ada tasks (Score:2)
A double linked list is the fastest deque implementation
If I was one of your students I'd demand a refund.
Re: (Score:2)
Structured parallelization has been done many times.
Re: (Score:2)
Granted, but I guess the appropriate level of snarkiness here depends on if by "new" they meant new concept or new to Java. As the title of TFA is "Get started with Java's new structured concurrency model" it sounds like the latter -- and the article seems to talk about it that way.
Re: (Score:2)
I guess the appropriate level of snarkiness here depends on if by "new" they meant new concept or new to Java
To the marketing people "new to Java" inherently implies "new".
Re: (Score:2)
These concurrency models are new (-ish) to Java. But they aren't new in parallel computing. New language constructs are good though.
Re: (Score:3)
"Virtual threads" are not even new to Java. They're just an opt-in return to Green threads [wikipedia.org].
Unsurprisingly, the syntax looks horribly clunky compared to OpenMP's #pragma omp parallel for.
Concurrency has been in java for a long time too (Score:5, Informative)
Of course, Ada has had concurrency with 'tasks' since 1981, and 40 years of experience implementing language semantics (both compilation/code generation and the runtime environment.) Ada83 had rendezvous for synchronization between tasks. Ada95 added protected objects to make it easier for tasks to avoid stepping on each other. A lot of the work on real-time scheduling (e.g. Rate Monotonic) came from people discussing how to implement Ada83 task scheduling where tasks can have different priorities, with Ada providing a common language to -describe the problem-.
But hey, there's no advantage in computer science for discovering your new shiny problem was addressed 40 years ago...
Java has had many means of "concurrency" since the 90s. The parallel stream introduced in Java 8 is the easiest to use multithreading mechanism I've personally ever seen. (I have no doubt someone else did it first, but I personally can't imagine anything easier to use than their parallel streams). Java is coming out with lots of new paradigms...either because they see the strategic importance or because they hired Brian Goetz...but concurrency is old news in Javaland.
Re: (Score:3)
The parallel stream introduced in Java 8 is the easiest to use multithreading mechanism I've personally ever seen.
Check out OpenMP syntax, available for boring old languages like Fortran, C and C++: https://www.cs.virginia.edu/lu... [virginia.edu] . In simple cases, it keeps the original program flow and only introduces new syntax to direct which bits run in parallel and how they share work or combine results.
"fork", seriously? (Score:2)
Why on earth did they decide to call thread creation "forking", when process creation has been called "forking" for 50 years? Is it to cause deliberate confusion, or was it designed by someone who's never heard of unix?
Re:"fork", seriously? (Score:5, Informative)
The parallel computing model that this enables to implement is called fork-join parallelism. It's a standard name in parallel computing and is also real old.
Wikipedia says 1963: https://en.wikipedia.org/wiki/... [wikipedia.org]
Re: (Score:3, Funny)
Re: (Score:2)
Why on earth did they decide to call thread creation "forking", when process creation has been called "forking" for 50 years? Is it to cause deliberate confusion, or was it designed by someone who's never heard of unix?
Remember this is probably design by committee. So it can be both. In any case, re-using a tem that has a different meaning in a closely related context is utterly dumb and really bad language design.
Re: (Score:2)
forking is not thread creation in Java.
Maybe because fork-join has been a thing for 60 years, before linux, posix, unix or multics existed.
Re: (Score:2)
When doing a fork. The difference between process creation and thread creations is only whether you copy the memory (usually with copy-on-write), of have both threads access the same memory.
Re: (Score:1)
Because forking a threat or forking a process is conceptually the same, just a different API?
But if you have a better name for "forking a new thread" I guess we are all "all ears".
Re: (Score:2)
Re: (Score:1)
You are correct with that.
Nevertheless the fork is a tool to either push manure onto the trailer of your tractor or food into your mouth.
Why no using the same word in different but similar contexts in programing?
Usually I'm the pedant if it is about correct usage of words, e.g. method versus methodology.
Of course, you could find different words, split of a thread e.g.
Sounds a lot like Ada tasks (Score:2)
Sounds a lot like the ease of using tasks in Ada but with the benefit of those tasks being lightweight threads.
Great idea!!
Oracle didn't kill it yet? (Score:1)
For the most part I have been seeing an Exodus from Java. Oracles license fees made it more risky to go the Java route. I am surprised Oracle is trying to improve features. That doesn't sound like Oracle.
You're clearly not a pro (Everyone uses openjdk) (Score:5, Informative)
For the most part I have been seeing an Exodus from Java. Oracles license fees made it more risky to go the Java route. I am surprised Oracle is trying to improve features. That doesn't sound like Oracle.
Hmm...wishful thinking. Java's popularity rises and falls slightly as new shiny languages emerge, but it always remains...unless you're talking about Java applets, then yes, we agree...those are dead. Server-side Java's credible threats, like kotlin, go, scala, and .NET never really got marketshare...and node.js and python are disasters for professional development at scale. Sorry, the number of job openings for Java is still high and most shops aren't dropping it. Node.js had a shot at overthrowing it and then people actually tried it out and realized what a disaster an untyped language is once it hits production, makes money, needs to scale, and then be handed off to someone other than the original author. Thus, I've seen a trend of companies starting server-side projects in node.js or python and migrating to something else, usually Java, after it's been in production for 5 years and is making money. Node.js and Python are perfectly fine for prototypes and small teams...but talented developers have a habit of not sticking around in the same role...either they find a new job, get promoted, or just leave the industry and retire or find something else they like doing better. That's when all the things that annoy you about Java come in handy.
Look, if you're whining and bitching about Oracle licensing fees, then you clearly don't work in the industry. Most people use Open JDK or they don't mind paying a fee. While it was a massive misstep on Oracle's part (Larry Ellison is a moron), it's the least of our worries or the worries of any company making money.
Java is stable and mature and popular and boring. It hasn't been exciting for a long time...just quietly getting the job done, scaling well, and performing well. It is deeply embedding in the majority of mission critical serverside apps and there's a massive pool of programmers familiar with it.
Someday Java will be dethroned, but I predict whoever replaces it will look a lot like Java. However, one thing to consider is that if you "fixed" Java and made it the most magical productive language that ever existed...you'd make me about 5-10% more productive. I spend VERY little time dealing with Java flaws or even writing pure code. Most of my time as a professional software engineer is either figuring out edge cases and requirements, wiring together existing libraries, or testing and documenting work I've done. Most business professionals don't write complex algorithms. Most of us are wiring together existing security, validation, and persistence libraries to fit a business use case...as well as working with stakeholders to figure out all the details of their business use case. No programming language will make my job, nor any other similar professional's job, much easier. Thus, you can complain about Java all you like and think Python, Kotlin, GO or someone else does it better....but their strengths matter very little for most working professionals.
Re: (Score:3)
Can it handle utf8 strings yet? Last time I checked there wasn't any real way to detect unicode punctuation, except "roll it yourself". Also what about unsigned integers?
I *want* to use a good, portable, garbage collected language, but there don't seem to be any. C++ is as close as I've found. (Well, D is better, but it doesn't have much library support.)
I'm pretty sure they do (Score:3)
Can it handle utf8 strings yet? Last time I checked there wasn't any real way to detect unicode punctuation, except "roll it yourself". Also what about unsigned integers?
I *want* to use a good, portable, garbage collected language, but there don't seem to be any. C++ is as close as I've found. (Well, D is better, but it doesn't have much library support.)
TMK? Yes...I'd have to know what you specifically mean to be confident. I know many people have written programs that handle Asian characters just fine. Our application handles some international text, but really, that's more a front-end domain problem. Java is primarily used for server-side programming...which is mostly taking data from the UI, confirming it's accurate, and putting it in a DB then reversing the process later. It's amazing how complicated something so simple can get.
Unsigned ints?
Re: (Score:2)
To me that sounds like the answer is "no".
You've got a use case for which Java is good. It's not the same as mine. And I'm not even talking about non-European languages. One *can* "roll one's own" method to handle detecting punctuation, and I've done it, but it isn't a part of the standard library.
FWIW, my use case doesn't involve connecting to the web at all, but does involve a lot of processing of big-endian binary files. parts of which are text and parts of which aren't. I could do it in C++, Python,
Re: (Score:2)
Support for unsigned integers might be coming someday, but doing that properly would require a major extension to the JVM - roughly doubling the number of supported instructions - if not an entirely new, word oriented bytecode format.
For memory efficiency reasons if Java were being designed from scratch they might make strings into a sequence of bytes without direct access by character index but that is incredibly unlikely change to make now for compatibility reasons. A change to a direct indexed 32 bit ch
Re: (Score:2)
Re: (Score:2)
Well, actually I'm retired now, after a lifetime of programmer/analyst/etc.
AFAIKT (admittedly not far) standard C++ is portable at the source code level. This is where the structure packing non-standardness is a real pain, but g++ recognizes what I understand is the MS extension for that. If you mean the binary isn't portable, that's definitely right. But that doesn't bother me. (Also, while I *want* the code to be portable, I'm not going to accept an MS license and pay them for the privilege of ensurin
Re: You're clearly not a pro (Everyone uses openjd (Score:1)
Lol. Not where I am at. We all use Python and node.js with a touch of typescript for our whole product stack across our AWS and Azure environment and have never seen scalability problems. I have not seen java servlets in a long time. They are quite niche like php these days.
Sounds like you need more senior level developers
No one uses Servlets anymore (Score:2)
Lol. Not where I am at. We all use Python and node.js with a touch of typescript for our whole product stack across our AWS and Azure environment and have never seen scalability problems. I have not seen java servlets in a long time. They are quite niche like php these days.
Sounds like you need more senior level developers
Servlets? Those have been out of fashion for 20 years. I haven't seen them in a long time either. However, like it or not, Java is very popular, especially among businesses and big spenders. It could be for a small piece or a hosted app, but I would be quite surprised if you couldn't easily find a Java backend in your organization, even if your focus is elsewhere. I'm not saying it's good or bad. I am just saying Java is ubiquitous and popular.
Re: (Score:2)
I agree that Java is very popular, but it seems to be popular mostly for being popular. I use one requirements management tool that's written in Java, providing a web interface to users, and regularly runs out of heap space -- with a 64 GiB heap limit, six users, and a database that fits under 10 MB of ReqIF (compressed XML, so hardly efficient). It's the same story for other web servers I see in Java: they seem to all use obscene amounts of memory and CPU for light loads.
Re: No one uses Servlets anymore (Score:2)
If you get OOMs with 64GB of heap and a small application, then the issue is definitely not the language.
The JVM has some overhead in memory and CPU usage, but nowhere near as much as you describe, it would have been dead long ago if it was a bad as you describe.
My guess is that your app is badly written, with some O(n^3) algorithms or some multiple joins that retrieve obscene amounts of rows from your DB and can cause OOMs before your ORM can aggregate the rows.
Not much the language can do against that.
Re: (Score:2)
Maybe you skipped the part at the end where I see the same thing with web services (from different companies)? It seems like using obscene amounts of memory is a common design pattern in Java.
Perhaps related, the Java runtime will consume VM until it hits its heap limit. That is how Java's GC is designed [stackoverflow.com] to work. That's 100% a language choice.
Re: (Score:1)
That is not how modern GCs work.
That was 20 years ago.
Modern GCs collect garbage and compact memory concurrently ... also since roughly 20 years.
I guess you did not have any contact to something Java related since 20 years, too.
Re: (Score:2)
Kind of like the other poster was saying, you don't know what you are doing. The fact that many developers working for many big companies are just like you doesn't mean anything. I have seen bloated programming in many languages. As a matter of fact, it seems more like the norm nowadays, don't matter the language used. I have many web applications I wrote in java which run just fine with 1GB heap, some with only 512MB, and some other with 256 and 128MB. It's people like yourself who gives Java a bad name! 6
Re: (Score:2)
It's not my code. It's one of several commercial applications that behave similarly when running web servers from Java applications. The company that made the app was the one that recommended we give it that much heap even for a small install. (I guess that's not as bad as another virtual appliance that won't even start properly unless it has 44 cores and 256 GB of RAM reserved.)
Maybe you shouldn't be so quick to assume other people are as ignorant and as bad at reading as you are.
Re: (Score:2)
Yet, you don't seem to hesitate to blame java! "I have seen many monstrosities coded in java so java is bad, I know for sure because I have seen many monstrosities coded in java".
Re: (Score:2)
Here, this program requires 256GB to run, seriously, I am not kidding:
#include
int main()
{ int i =0;
for (i=0; i262144; i++)
{
void *m = malloc(1024*1024);
memset(m,0,102
Re: (Score:2)
Yes, there are a lot of monstrosities coded in Java. On the other hand, people here claim their shit doesn't stink. I know which evidence I find more convincing.
See comparisons like https://deepu.tech/concurrency... [deepu.tech] -- the Java solutions use several times as much memory as the non-Java solutions. In the second "drill" benchmark, 1 GB vs 20 MB -- with the 20 MB solutions running faster than Java to boot. https://medium.com/deno-the-co... [medium.com] has similar results. The memory inefficiencies are hardly limited
Re: No one uses Servlets anymore (Score:2)
Java has overhead, of course, but if a fairly simple webapp OOMs with 64GB of heap, the problem isn't Java's overhead.
Re: (Score:2)
Hey! I just checked and I have at least 3 java daemon running with a 32 MB heap! Again, when you don't know what you are doing, it's easy to go trash java on "Stackoverflow" instead of actually learning how to code. lol!
I have done similar benchmarks myself and java came on-par with C. The trick is to let the JVM warm up and do its optimization with JIT or what not. On the first run, it will be slower but after only a few requests, it will come on-par.
It's amazing how many propeller heads think just like yo
Re: (Score:2)
Yes, you're a blowhard idiot fanboi who ignores mountains of evidence in favor of his preferred narrative. We got it from your first comment.
Re: (Score:2)
Indeed, got to be a fanboy to know how to code properly. LOL! I couldn't care less about java and use several languages. I also laugh at propeller heads trashing java because they can't figure out better. That's where all your "evidence" comes from! Java fanboys are often the worst developers because they have a tendency to try to use all the fancier constructs they can find, bloat the code with way too many interfaces, etc. etc. :)
Re: No one uses Servlets anymore (Score:2)
The fact that many apps you use are bad doesn't mean it's necessarily the language. Java isn't used as much as it is for no reason, if it had such glaring flaw, it wouldn't.
The jvm uses as much memory as its given the same way an OS uses as much ram as it has. If it has spare memory, it keeps stuff in memory and just garbage collects less, only when you near the limit.
It's the difference between free and available memory.
But if you get an OOM, it's not because Java doesn't garbage collects because you have
Re: (Score:2)
Just like people regularly writing buggy code in C is their own fault for having security holes, and doesn't say anything about the language?
Re: (Score:2)
Yeah of course, a nice programming language should run any trash programmer code very efficiently with no security holes since there are way too many propeller head developers around for us to be able to have anything else.
Re: (Score:2)
Correlation doesn't equal causation, and your little dataset of a few badly written apps doesn't mean much in the face of the dataset of half of the industry running well on java.
Java's overhead is not the reason your applications suffer OOM, again.
They either have a memory leak, and Java doesn't make it any easier than other languages to create one, and make it way harder than some, so congratulation.
Or they actually use obscene amounts of memory, in which case that's not the fault of the language either.
Re: (Score:1)
Then "the Tool" probably has a memory leak and you should file a bug report?
Or convince "operations" to restart it over night?
It's the same story for other web servers I see in Java: they seem to all use obscene amounts of memory and CPU for light loads.
Yeah and I run mine in about 1MB.
Can't be so hard to grasp that your tool, or what ever it is, has a programming bug that causes a memory leak. Can happen in any language.
No platform is safe from bad developers (Score:2)
I agree that Java is very popular, but it seems to be popular mostly for being popular. I use one requirements management tool that's written in Java, providing a web interface to users, and regularly runs out of heap space -- with a 64 GiB heap limit, six users, and a database that fits under 10 MB of ReqIF (compressed XML, so hardly efficient). It's the same story for other web servers I see in Java: they seem to all use obscene amounts of memory and CPU for light loads.
Hmm, I have a few millions users per week, running across 10 nodes and I think each node has a Gigabyte or 2....never ran out of memory once in 10 years. Java scales well, but you have to actually write it correctly. If you're running out of RAM, that's not Java's fault, that's the fault of whomever wrote that app. Garbage collection is not magic. It can't undo stupid. If you hold onto a reference for objects and duplicate them over and over, GC assumes you're not an idiot and are doing it for a reason
Re: (Score:2)
Same here! And just as I posted above; he is obviously doing it wrong just like many developers working for big companies which don't know what they are doing. If you give inexperienced developers a powerful tool, chances are they'll somehow manage to shoot themselves in the foot. Then, they end up bitching about how bad java is in the forums, typical phenomenon.
Re: (Score:1)
I agree that Java is very popular, but it seems to be popular mostly for being popular. I use one requirements management tool that's written in Java, providing a web interface to users, and regularly runs out of heap space -- with a 64 GiB heap limit, six users, and a database that fits under 10 MB of ReqIF (compressed XML, so hardly efficient). It's the same story for other web servers I see in Java: they seem to all use obscene amounts of memory and CPU for light loads.
That's strange, we write online banking software and most of our services run just fine in 128 megs of heap. We have a couple that deal with database tables with millions of rows that need a little more, Something is seriously wrong with your app.
Re: (Score:1)
Servlets? Those have been out of fashion for 20 years. I haven't seen them in a long time either. However, like it or not, Java is very popular, especially among businesses and big spenders. It could be for a small piece or a hosted app, but I would be quite surprised if you couldn't easily find a Java backend in your organization, even if your focus is elsewhere. I'm not saying it's good or bad. I am just saying Java is ubiquitous and popular.
Pretty much everyone who is deploying a backend web basede API with Java is using Servlets. They might just not know it. Spring MVC uses a servlet, Quarkus, Micronaut, etc. They all have at least one Servlet. Which is why those apps can be deployed to a Servlet container like Tomcat, Jetty, Undertow, etc. For example, Spring MVC has a single DispatcherServlet that users of Spring MVC simply don't need to care about. But that doesn't mean it isn't there.
Re: (Score:2)
Yeap! It's servlets all the way down! (Like it's the case for turtles), even although not obvious for the common propeller head developer. As I wrote above, I just checked and I have at least 3 multi-threaded daemons running with 32MB heap in prod for ages (no web no servlets there).
I don't have time to search for who posted that, but they are probably confused with applets.
That's a silly technicality (Score:2)
If you want to go down that rabbit hole, when I am working with Spring Boot, there's C code in the JVM, maybe some Assembly?...but I don't complain about C or consider it a part of my stack.
Re: (Score:2)
Re: (Score:1)
Look, if you're whining and bitching about Oracle licensing fees, then you clearly don't work in the industry. Most people use Open JDK or they don't mind paying a fee. While it was a massive misstep on Oracle's part (Larry Ellison is a moron), it's the least of our worries or the worries of any company making money.
I am not sure what you mean here, Oracle open sourcing Java was a great step (started by Sun but finished by Oracle), there was no mistake made. I think you and many other people are confused about what OpenJDK is. OpenJDK is Oracle's open source implementation of the Java SE specification licensed GPL v2 with classpath exception. Because it is GPL other vendors can offer builds of OpenJDK sources and sell support if they want to. Azul does this, and RedHat offers support for their OpenJDK builds as part o
Re: (Score:2)
OpenJDK is carrying the torch well enough that people don't need Oracle.
Re: (Score:1)
OpenJDK is carrying the torch well enough that people don't need Oracle.
This is a very strange comment. OpenJDK is Oracle's open source implementation of the Java SE specification. OpenJDK _is_ Oracle. All the Java language architects also work for Oracle and Oracle is the biggest contributor to OpenJDK in both money and developers. So Java definitely needs Oracle.
Re: (Score:2)
Oracle killed Oracle Java
They basically told everyone to move to OpenJDK with their licensing model.
Re: (Score:3)
Or Amazon Corretto. We have a heavy monolith and dozens of microservices using their distributions. No fuss no muss.
Re: (Score:1)
Or Amazon Corretto. We have a heavy monolith and dozens of microservices using their distributions. No fuss no muss.
But Amazon Corretto is built from OpenJDK and OpenJDK is Oracle's open source implementation of the Java SE specification. You seem to be confused about what OpenJDK is.
Re: (Score:1)
Oracle killed Oracle Java They basically told everyone to move to OpenJDK with their licensing model.
Well yeah, if you don't need/want commercial support from Oracle then you don't use their commercial build of OpenJDK which they call Oracle JDK. Instead use a GPL build of OpenJDK (which Oracle also provides at https://jdk.java.net/ [java.net] or another build of OpenJDK from your favorite Java vendor. Remember that OpenJDK is Oracle's open source implementation of the Java SE specification. As far as I know there is no other Java SE implementation. All vendors (including Oracle themselves) build from OpenJDK. (this
Developers cannot do concurrency (Score:1)
At least for anything relatively closely coupled. Most developers are just not smart enough for that. It is really a waste of time investing into making the interface for implementation of concurrency easier. 99% of the complexity is not from what the language offers.
Re: (Score:2)
All or nearly all user interface developers have to deal with some form of concurrency. Javascript has a particularly unfortunate one that almost all web developers have to deal with for example, and they can't exactly fix that problem anytime soon. Cooperative multithreading with blocking requests is so much easier to develop for and reason about than asynchronous callbacks for everything.
Re: (Score:2)
Indeed, this seems to me like one more opportunity for inexperienced developers to shoot themselves in the foot! Hey look! Threads are easy now! Devs shoot themselves in the foot and end up even more often in the forums bitching about java and how bad it is. I have been doing multi-threaded programming in java since the beginning, so since 1998.
ExecutorService (Score:2)
I wonder if this would've helped with a project I was working on years ago. To drastically oversimplify, I needed to determine the value of an account for each day since the account's inception. An account is made up of assets, so we could create one thread per day per asset. We can't calculate the
Re: (Score:2)
Your thinking is narrowed down on to threads. You seem to be trying to fit a solution to a problem.
Your problem is describing tasks. Tasks that may create new tasks when they complete.
Swift uses structured concurrency also (Score:1)
Interesting that Java went this way, Swift is also using Structured Concurrency for the async/await features added a few years ago. Very nice, hopefully it's as helpful for Java coding.
Structured concurrency was so useful that when it was introduced, at first it was not going to be backwards compatible but the developer community pushed Apple into supporting one version earlier of iOS, so it goes all the way back to iOS 13 (though system libraries that use async/await are not present until later iOS versio
Re: (Score:2)
Does not look new to me (Score:2)
I'm not a java programmer, but this just looks to be creating threads with a callback for each and then syncronizing with a join.
Re: (Score:2)
I haven't looked at it but you are probably correct! You explanation makes a lot of sense to me!
Is it truly new? Who cares? (Score:2)
I knew the second I saw the title that people would descend complaining about "prior art". And, naturally, they did.
So, is it useful? Does it make some things easier? Can it increase productivity? These are the important questions.
Far less interesting, what other competing modern languages provide similar constructs? Telling me Ada had something is about as useful as telling me you prefer the color adjustment pots on the back of the neck on the crt in your 1980 Zenith tv set.
Re: (Score:2)
People love to hate Java. When it gets new features, someone inevitably will comment well "blah blah blah had it first." But seriously, the first comments in this vein were talking about Ada, for fuck's sake. As I said, people just love to hate Java.
Re: (Score:2)
Re: (Score:2)
+ 1 informative!
Looks like C# Parallel.ForEach (Score:2)
Parallel.ForEach(list, item => // Do stuff here with each item in the list, in a separate thread
{
});
Is Java slow to the party, or am I missing something?