Home	Talk	Things you can do	Sandbox	New	Peer review	Assessment	Announcement	Java Cafe

This is the talk page for discussing WikiProject Java and anything related to its purposes and tasks.

Put new text under old text. Click here to start a new topic. New to Wikipedia? Welcome! Learn to edit; get help. Assume good faith Be polite and avoid personal attacks Be welcoming to newcomers Seek dispute resolution if needed Shortcuts WT:JAVA WT:JAVAP

Archives: Index, 1Auto-archiving period: 60 days

Java Project‑class

This page is within the scope of WikiProject Java, a collaborative effort to improve the coverage of Java on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.JavaWikipedia:WikiProject JavaTemplate:WikiProject JavaJava articles Project This page does not require a rating on Wikipedia's content assessment scale.

WikiProject Java was featured in a WikiProject Report in the Signpost on March 2010.

Most of server based applications, like Web servers, database servers, or mail servers, are responsible for controlling a large number of tasks that arrive from some remote source it can be fast task.
Any request can received by the servers in any manner, which can be from a network protocol (HTTP, FTP, or POP), through a JMS queue, MQ, myth be by polling a database or any socket based connection. It’s often the case in server applications that the processing of each individual task is short-lived and the number of requests is large.
One simplistic model for building a server application would be to create a new thread each time a request arrives and service the request in the new thread.
This approach actually works fine for prototyping, but has significant disadvantages that would become apparent if you tried to deploy a server application that worked this way. One of the disadvantages of the thread-per-request approach is that the overhead of creating a new thread for each request is significant; a server that created a new thread for each request would spend more time and consume more system resources creating and destroying threads than it would processing actual user requests.
A thread pool offers a solution to thread life-cycle overhead and the resource thrashing. By reusing threads for multiple tasks, the thread-creation overhead is spread over many tasks. As a bonus, because the thread already exists when a request arrives, the delay introduced by thread creation is eliminated. Thus, the request can be serviced immediately, rendering the application more responsive. Furthermore, by properly tuning the number of threads in the thread pool, you can prevent resource thrashing by forcing any requests in excess of a certain threshold to wait until a thread is available to process it.

Dear Ehsaniara, many thanks for your invaluable contribution to this project. I don't see much Java stuff in there so may we point you to the Thread pool pattern article... The only intriguing thing is that your bit is not as well 'written' as the source you took it from... AR 18 December 2009, 14:36 (UTC)

Hello Wikiproject! Currently there is a discussion which will decide whether wikipedia will delete 49,000 articles about a living person without references, here:

Wikipedia:Requests for comment/Biographies of living people

Since biographies of living people covers so many topics, nearly all wikiproject topics will be effected.

The two opposing positions which have the most support is:

1. supports the deletion of unreferenced articles about a living person, User:Jehochman
2. opposes the deletion of unreferenced articles about a living person, except in limited circumstances, User:Collect

Comments are welcome. Keep in mind that by default, editor's comments are hidden. Simply press edit next to the section to add your comment.

Please keep in mind that at this point, it seems that editors support deleting unreferenced article if they are not sourced, so your project may want to pursue the projects below.

I have (with the help of others) made a small user script to detect and highlight various links to unreliable sources and predatory journals. Some of you may already be familiar with it, given it is currently the 39th most imported script on Wikipedia. The idea is that it takes something like

• John Smith "Article of things" Deprecated.com. Accessed 2020-02-14. (John Smith "[https://www.deprecated.com/article Article of things]" ''Deprecated.com''. Accessed 2020-02-14.)

and turns it into something like

• John Smith "Article of things" Deprecated.com. Accessed 2020-02-14.

It will work on a variety of links, including those from ((cite web)), ((cite journal)) and ((doi)).

The script is mostly based on WP:RSPSOURCES, WP:NPPSG and WP:CITEWATCH and a good dose of common sense. I'm always expanding coverage and tweaking the script's logic, so general feedback and suggestions to expand coverage to other unreliable sources are always welcomed.

Do note that this is not a script to be mindlessly used, and several caveats apply. Details and instructions are available at User:Headbomb/unreliable. Questions, comments and requests can be made at User talk:Headbomb/unreliable.

- Headbomb {t · c · p · b}

This is a one time notice and can't be unsubscribed from. Delivered by: MediaWiki message delivery (talk) 16:01, 29 April 2022 (UTC)Reply[reply]

A discussion is taking place as to whether the article AppletViewer is suitable for inclusion in Wikipedia according to Wikipedia's policies and guidelines or whether it should be deleted.

The article will be discussed at Wikipedia:Articles for deletion/AppletViewer until a consensus is reached, and anyone, including you, is welcome to contribute to the discussion. The nomination will explain the policies and guidelines which are of concern. The discussion focuses on high-quality evidence and our policies and guidelines.

Users may edit the article during the discussion, including to improve the article to address concerns raised in the discussion. However, do not remove the article-for-deletion notice from the top of the article until the discussion has finished.