Talk:Java (software platform)

JRE 6.0 update 24

I updated the latest release in the box. I'm using the last modified date of the release notes page, because I can't find a more accurate release date. If anyone knows, or knows how to find out. Please change it, and if they wouldn't mind posting here, so I can see how to figure it out as I don't doubt ,., m m

Quality is appalling

The article's quality is appalling! sentences and language use are pretty bad. This will need some work! Npovmachine 16:03, 19 August 2006 (UTC)

Programming language

I felt it necessary to significantly modify the Language section of this page to address perceived bias and better reflect the more thorough Java programming language article. In addition, I may have inadvertantly inserted my own bias by promulgating the "less-pure" meme. Please feel free to do what you will. --gortsack 20:47, 17 April 2006 (UTC)

You edits were on target, you just didn't go far enough.  :-) I worked on it some more, but it was pretty poorly worded compared to the Java programming language article that most of this content was taken from. —Doug Bell ^{talk•contrib} 18:58, 19 April 2006 (UTC)

problems!

I disagree very strongly with the following statement made in the article:

Standalone applications have fallen out of favor as computing has switched to a Web-based model. New programming techniques have produced powerful Web applications....

The advent of portable drives, knoppix, etc. contradicts the preceding statement. The demand for small, self-contained, and portable binaries is higher than ever. Take for example, utorrent.

(The following paragraph contradicts itself, and my own personal experience is that 1.5 and 5.0 apps don't get along with just one JRE, so I purposefully avoid all Java to preclude 500Mb of JRE ;) )

...Because of incompatibilities between different versions of the JRE, rather than rely on pre-installed JREs, many applications install their own JREs in order to function predictably. Java applets can detect which version of Java they are running on and the high level of compatibility between different versions of Java ensures it is a simple matter to support older versions of Java whilst making use of the additional features of later versions.

I've found a high level of compatibility between Java versions, to the extent that the same byte code runs on all versions. See Clesh for one example (needs broadband). Also, services like Google mail and in fact Google itself have become more popular and these are web based applications. Stephen B Streater 22:01, 5 June 2006 (UTC)

why isnt OOo being mentioned as a good example for a nice java-desktop app?

because it isn't one, its a C++ app that happens to use a tiny bit of java for its scripting functionaility. Plugwash 23:14, 7 July 2006 (UTC)

I have suffered from the JRE incompatibility problems referred to above, but not being an expert in Java, I've added cleanup tags to two sections, and added fact tags to some statements. In fact some compatibilty claims in the article are directly counter to my experiences but I guess that would be OR. -Wikianon 11:04, 22 September 2006 (UTC)

I do not understand what is meant by the Criticism section when it states that Java necessarily uses "a user's IP address to allow Java to function." I've used Java for years, and don't know what this means. There is a bug opened on Java 1.5.0 through 1.5.9 (I believe) where calling some network functions tried doing a reverse DNS lookup on the remote IP address, but this was a bug that has been since fixed, not a feature of the langauage. There are plenty of valid critiques of Java, I just don't think this is one of them (factually). If not clarified, this section should be removed. Dov Wasserman 19:19, 28 March 2007 (UTC)

I put a after the sentence, and I agree that it seems to be original research (and maybe false). I propose to delete the entire Criticism section (it contains only this sentence) if nobody is able to cite sources in a few days. Plus, even if there are sources, I think the sentence should be : clarified + put in the general Criticism of Java article. The sentence says exactly the contrary as a LOT of sources always say : Java is generally a secure language. Hervegirod 21:57, 28 March 2007 (UTC)

don't merge

we tried having the top level java article and the programming language as one article and it was frankly a mess with the "java as a whole" people constantly fighting over what the article should contain with the "java programming language" people.—The preceding unsigned comment was added by Plugwash (talk • contribs) 23:21, 15 September 2006 (UTC).

I agree, so I'm removing the merge tags. Someone can always readd the merge and include reasons that might gain consensus in the two Talk pages. -Wikianon 11:22, 22 September 2006 (UTC)

Version history

I think that this article is too long. Why not split the "Version History" part in another article, to link with this one, or at least keep only the beginning of the chapter in this article, and put the detailed J2SE 1.0 to 7.0 to the new article ? Hervegirod 09:33, 28 October 2006 (UTC)

No answer, I took it as a yes Hervegirod 11:44, 4 November 2006 (UTC)

GPL

is there actually any official sun download marked up as GPL yet, if not then imo we are jumping the gun saying that java has been made GPL. Plugwash 00:54, 16 November 2006 (UTC)

ok i just took a look at https://openjdk.dev.java.net/ and it seems that the vm and the compiler are already gpl but the class libraries (which are arguablly the most valuable part of java to have under a free software license) are not going to be until early 2007. Plugwash 00:57, 16 November 2006 (UTC)

javac and hotspot are GPL now, and they really are valuable pieces of software (think of the speed of Sun's vm compared to other free vms, for example). Hervegirod 12:02, 25 December 2006 (UTC)

javac is very low value. The java language to java bytecode conversion isn't that complex and there are perfectly acceptable free compilers out there. Hotspot is more valuable but i'd imagine it has a fairly strong dependency on suns class libraries which are still non-free. If and when we see a buildable JRE made up of opensource software then that WILL be a very significant moment but what we have been given so far is practically worthless on its own. Plugwash 23:12, 5 April 2007 (UTC)

Licensing

There really shouldn't be a "past and present" division about free software licensing of Sun's JRE or class library because it still isn't free, and according to Sun it won't be free until at least March. Even if/when Sun Java becomes free, the before and after sections would probably not be useful for such a small set of information. Also, in the english language, saying "Java wasn't free software" (past tense) can imply that it has changed from non-free to free, which wouldn't be accurate. If it wasn't free software, and it still isn't, then you would use a current tense, or if you must refer to the past, "has never been" would be clear.

The Licensing section also needed some major cleanups in a variety of ways. I've tried to make the section more concise and clear without removing anything important, but if I did remove something important, please re-add it, rather than reverting the entire edit. 64.59.144.21 02:05, 21 December 2006 (UTC)

Desktop Use

Two of the claims are not fact-based and maybe not relevant:

• Tools used to develop graphical Java applications are fragmented and none is as popular as Microsoft's Visual Studio suite for developing Windows applications: I never seen any comment about this on the web, especially to explain why Java is not widely used on the desktop.

This also appears to be a very strange claim that Microsoft's Visual Studio suite is more widely used for developing Graphical Java applications than eclipse. I suspect 5 years ago this may have been close to the truth, but I would be amazed if it is true now.

Netbeans for teh win! In all seriousness though, there are plenty of excellent free solutions out there, such as Netbeans and Eclipse. Without fighting over which of the free solutions is better (Netbeans would win that hands down anyway), it is redicilous to assume that (esp. without statistical evidence) a solution that costs tons of money, and is primarily meant for .NET/C++ would be the ideal of preferred development means for Java. My apologies for being anonymous btw :P

• There are multiple versions of the JRE, which can introduce compatibility issues for Java applications installed on a system: this is the same with ANY other language / platform, as C#, Python, Perl, even Flash, and as Java is (for the most part) upward compatible, especially at the binary-level, I think it is not a problem ; also, I never seen this explained as a weakness of Java which could reduce its desktop adoption (except on Wikipedia..).

Isn't this a reference to the old conflict between the Microsoft Java VM and the Sun Java VM? In that case, there really were incompatibilities. Which IMHO, was a pretty shitty thing to do on MS's part. However, the lawyers settled this and now Sun's VM is considered the "real one" and others that are developed (open source ones for example) are modelled after the Sun one, for compatibility. Especially since the vast amount of platforms on which a Java VM is supported, this seems to be a thing of the past. Just my 2 cents... —Preceding unsigned comment added by 80.61.108.218 (talk) 14:05, 5 March 2008 (UTC)

• The claims seen on the net are Java memory usage, Java mostly don't follow platform GUI guidelines, extra-step to deploy Java-based apps (even if it is the same with a lot of other frameworks), and Java being non-free in the past. Hervegirod 12:34, 27 May 2007 (UTC)

Don't forget the rest of the World

If this article is going to talk about the language/API that Sun created, then it should mention each of the implementations. Java is a successful technology and has fostered a community and a market of it's own. The current text makes it look like Java is something that only Sun is interested in, and no one else wants to, feels a need to, or sees a reason to develop this technology. ...which obviously isn't true.

If, on the other hand, this article is to be limited to Sun's Java implementations, then it should be renamed as such and the discussion of the general Java technology (which Sun develops/defines) should be moved to an article that is broad and inclusive.

I think the broad approach is better - aiming to make this a "top level" article for Java, rather than limiting it to the overlap of the technology and the company. To broaden this, info can be found on free Java implementations (about GNU Classpath, GNU Compiler for Java, Kaffe, Apache Harmony, etc.). There is also Blackdown Java, and probably others. Gronky 15:30, 25 June 2007 (UTC)

Merge

Convention is that merge discussion takes place on the mergee, but adding a note here as a heads-yp. These articles cover the same ground, and regardless of the final title there should only be one of them. Chris Cunningham 10:17, 11 September 2007 (UTC)

Requested move

I propose that this article be moved over the redirect Java Platform. The current disambig parenthetical (Sun) is self-defeating in that it is highly ambiguous, as it could be interpreted as being the name of a star. "Java Platform" is the official proper name of the subject being addressed in the article and will not require disambiguation for the foreseeable future. If "platform" is too specific, other candidates might be Java (software) or Java (computing). In any case, (Sun) has to go. Ham Pastrami (talk) 05:24, 23 April 2008 (UTC)

• rename to' Java (computing), since "Platform" requires a person know what a computing platform is, instead of say, an oil platform off the coast of the island of Java. 70.55.200.157 (talk) 03:43, 24 April 2008 (UTC)

• Yes, I think Java (computing) makes the most sense. Klausness (talk) 10:05, 24 April 2008 (UTC)

"Java Platform" is not an "official proper name"; it's a random subset of the various "official proper names" that the platform currently goes by. It's no less contrived than "Java (Sun)". Both "Java (software)" and "Java (computing)" are ambiguous because of the existence of Java (programming language). I'd settle for Java (software platform) as a compromise, but the other suggestions thus far are definitely inappropriate. Chris Cunningham (not at work) - talk 12:13, 24 April 2008 (UTC)

That makes sense. I like Java (software platform). Brainsik (talk) 22:30, 24 April 2008 (UTC)

Relisting as -> Java (software platform), which I support. Andrewa (talk) 00:53, 29 April 2008 (UTC)

In all its incarnations it is known as "Java Platform", appended by a particular edition. They are all referred to as "Java Platform", however.[1] It is blatantly obvious that this is an appropriate title, though whether it is the best title for the wiki is another question. If you know of any other nomenclature that is used consistently in official documents, please share some examples with us. Java (software platform) is fine by me, as the only difference is using the trademark vs using a generic phrase. Also, I don't consider Java (programming language) to be a problem for ambiguity, as the language is in fact part of the platform. That is, if you wanted to reference the Java language, you would not be incorrect in linking this article, even though a more specific article exists. Ham Pastrami (talk) 05:10, 29 April 2008 (UTC)

Errr, Sun doesn't hold a trademark for "Java Platform". As for consistency, there's really no such thing in this particular case. The only constant is "Java", so rather than second-guessing we should just use "Java" and disambiguate it. Chris Cunningham (not at work) - talk 07:02, 29 April 2008 (UTC)

Wikipedia:naming conventions don't place any emphasis on what is used in official documents, whether consistently or otherwise, rather they focus on what the greatest number of English speakers would most easily recognize, which may or may not be the same thing. While I respect your opinion that it is blatantly obvious that the correct title is Java Platform, some of us disagree. Andrewa (talk) 09:10, 29 April 2008 (UTC)

Java's Critisism?

Why is there nothing about Java's criticism? For example, many people complain that Java runs to slow, and teaches bad habits to beginning programmers. Bit101 (talk) 01:05, 25 May 2008 (UTC)

There's already a whole article devoted to Criticism of Java. There's also a smaller Criticism section in the Java (programming language) article, so I think we have enough material on this subject (adding more sections about that would duplicate already existing material). I have linked the Criticism of Java article in the See also section. Hervegirod (talk) 08:55, 25 May 2008 (UTC)

Image copyright problem with Image:Java Logo.svg

The image Image:Java Logo.svg is used in this article under a claim of fair use, but it does not have an adequate explanation for why it meets the requirements for such images when used here. In particular, for each page the image is used on, it must have an explanation linking to that page which explains why it needs to be used on that page. Please check

• That there is a non-free use rationale on the image's description page for the use in this article.
• That this article is linked to from the image description page.

This is an automated notice by FairuseBot. For assistance on the image use policy, see Wikipedia:Media copyright questions. --23:33, 16 September 2008 (UTC)

history section

First sentence in the history section broken and I can't fix it myself. ike9898 (talk) 16:57, 3 June 2009 (UTC)

"While considering moving to NeXT, Naughton was offered[by whom?] a chance to work on new technology, and thus the Stealth Project started." The offer was from Wayne Rosing : http://www.blinkenlights.com/classiccmp/javaorigin.html. Is it OK if I rewrite it ? jojiantony —Preceding undated comment added 12:08, 7 November 2015 (UTC)

64-bit support

Does Java have 64-bit support? 83.108.194.198 (talk) 16:59, 22 January 2010 (UTC)

Yes. Haakon (talk) 17:01, 22 January 2010 (UTC)

Native? And for both open source and Sun Microsystem version? 83.108.194.198 (talk) 17:07, 22 January 2010 (UTC)

Yes, check out the different downloads here. OpenJDK can be built for 64-bit. I'm not sure if that is what you mean by native. A 64-bit build does not give you access to a different set of primitives, for instance. Haakon (talk) 17:26, 22 January 2010 (UTC)

Maybe it was Flash Player I thought as of having only 32-bit support... 83.108.194.198 (talk) 20:16, 22 January 2010 (UTC)

I should say that until recently, there was no 64-bit Java browser plugin. That changed less than half a year ago, I think. Also, there is now a 64-bit flash plugin for Linux. Haakon (talk) 20:23, 22 January 2010 (UTC)

c programming language

how is pointer initialized? —Preceding unsigned comment added by 124.124.162.38 (talk) 13:01, 1 February 2010 (UTC)

Spoken Wikipedia Audio Recording

I've created an audio recording of this article for the Spoken Wikipedia project. Please let me know if I've made any mistakes. Thanks. --Mangst (talk) 23:06, 27 December 2010 (UTC)

Sun and Oracle

Throughout the article, Java is talked about in reference to Sun, and there is no mention of Oracle's acquisition of Sun. Is Sun really a "subsidiary" of Oracle, as the intro section suggests?Glasr5339 (talk) 12:55, 15 December 2011 (UTC)

Plain ol' Duke/Wizards Connection?

For years I have noticed that Plain ol' Duke looks a little like a scene out of the movie Wizards (1977)where Avatar waves at Black Wolf. Just a thought. Septagram (talk) 05:03, 27 May 2012 (UTC)

Mobile platforms update

iOS, Android? Anyone heard of those? ;) Do they support Java or not? --Xerces8 (talk) 19:24, 14 September 2012 (UTC)

iOS: yes, but not officially; Android: yes. –C5st4wr6ch (talk) 17:10, 13 February 2013 (UTC)

iOS: no it is not supported. https://en.wikipedia.org/wiki/IOS_SDK#Java Gürkan Sengün (talk) 09:04, 18 September 2013 (UTC)

Heading text

How to develop mail marge program in java ? — Preceding unsigned comment added by 27.34.64.106 (talk) 04:57, 7 April 2014 (UTC)

java

can you tell me name of applications of java a and where we uses java. — Preceding unsigned comment added by 117.241.108.46 (talk) 05:21, 20 September 2014 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to 2 external links on Java (software platform). Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

• Added archive http://web.archive.org/web/20110814034947/http://shootout.alioth.debian.org/u64q/which-programming-languages-are-fastest.php to http://shootout.alioth.debian.org/u64q/which-programming-languages-are-fastest.php
• Added archive http://web.archive.org/web/20110926210432/http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=javasteady&lang2=gpp to http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=javasteady&lang2=gpp

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 09:54, 21 March 2016 (UTC)

akshit

akshit is a very good by and he will beat dhairya and bring 10 cgpa — Preceding unsigned comment added by 115.97.103.88 (talk) 06:48, 9 April 2016 (UTC)

Software Engineering

Software Engineering:- Software is the collection of computer programs, procedures, rules, associated documentation and data which are collected for specific purpose. Software is the various kinds of programs used to operate computers and related devices. A program is a sequence of instructions that tells a computer what operations to perform. Programs can be built into the hardware itself, or they may exist independently in a form known as software. Hardware describes the physical components of computers and related devices. According to IEEE “software is a collection of computer programs, procedures, rules and associated documentation and data pertaining to the operation of a computer system.” Software is often divided into two categories, system software or industrial strength software and Application software or simple software. Application software is a simple program that is usually designed, developed, used and maintained by the same person. No systematic approach is required for such type of software’s. System software use some systematic approach called programming systems. Different users in different platform use these software’s and the complexity is high. System software includes operating systems and any program that supports application software. • Software Characteristics For a better understanding of the software, it is important to examine the characteristics of software that make it different from other things that human beings build. When hardware is built, the human creative process (analysis, design, construction, testing) is ultimately translated into a physical form. If we build a new computer, our initial sketches, formal design drawings, and bread boarded prototype evolve into a physical product (chips, circuit boards, power supplies, etc.). Since software is purely logical rather than a physical system element, it therefore, has characteristics that are entirely different than those of hardware:

1. Software is developed or engineered but it is not manufactured in the classical sense:

Although some similarities exist between software development and hardware manufacture, the two activities are fundamentally different. In both activities, high quality is achieved through good design, but the manufacturing phase for hardware can introduce quality problems that are nonexistent (or easily corrected) for software. Both activities depend on people, but the relationship between people applied and work accomplished is entirely different. Both activities require the construction of a “Product”, but the approach is different.

2. Software doesn't wear out: Figure below shows the failure rate as a function of time for hardware.

The relationship, often called the "bathtub curve," indicates that hardware exhibits relatively high failure rates early in its life (these failures are often attributable to design or manufacturing defects); defects are corrected and the failure rate drops to a steady state level (ideally, quite low) for some period of time. As time passes, however, the failure rate rises again as hardware components suffer from the cumulative affects of just, vibration, abuse, temperature extremes, and many other environmental changes. The hardware begins to wear out. Software is not susceptible to the environmental changes that cause the hardware to wear out. Theoretically the failure rate curve for the software should take the form shown below. 3. Most software is custom-built, rather than being assembled from existing components : Consider the manner in which the control hardware for a computer-based product is designed and built: The design engineer draws a simple schematic of the digital circuitry, does some fundamental analysis to ensure that proper function will be achieved, and then refers to the catalog of digital components Each IC has a part number, a defined and validated function, a well-defined interface, and a set of integration guidelines. After each component is selected, the circuit is implemented. A software component should be designed and implemented so that it can be reused in different programs since it is a better approach, according to finance and manpower. In the 1960s, we built scientific subroutine libraries that were reusable in a broad array of engineering and scientific applications. These subroutine libraries reused well-defined algorithms in an effective manner but had a limited domain of application. Today, we have extended our view of reuse to encompass not only algorithms but also data structure. Modern reusable components encapsulate both data and the processing applied to the data, enabling the software engineer to create new applications from reusable parts. • Software Myths Many causes of a software affliction can be traced to a mythology that arouse during the early history of software development. Software Myths propagate misinformation and confusion. Software Myths had a number of attributes that made them insidious: They appeared to be reasonable statements of facts, and they were often accepted by experienced practitioners. Today, most knowledgeable professionals recognize myths for what they are- misleading attitudes that have caused serious problems for managers and technical people. However, old attitudes and habits are difficult to modify, and small traces of software myths are still believed.

Management Myths Managers with software responsibility, like managers in most disciplines, are often under pressure to maintain budgets, keep schedules from slipping, and improve quality. Often the software manger believes the software myth as it lessens the pressure temporarily.

Myth: We already have a book that's full of standards and procedures for building software. Won't that provide my people with everything they need to know? Reality: The book of standards may exist, but is it used? Are software developers aware that it exists? Does it reflect modern software development practice? Is it complete? In many cases the answer to these questions is no.

Myth: My people have the latest software development tools; after all we do buy them the latest computers. Reality: It takes more than the latest computer to do high quality software development. Computer-aided software engineering (CASE) tools are more important than hardware for achieving good quality and productivity, yet the majority of software developers still do not use them.

Myth: If we get behind schedule we can add more programmers and catch up. Reality: Software development is not a mechanistic process like manufacturing. In the words of Brook: '...Adding people to a late software project make it later'. As new people are added, those who were originally working on it must spend time educating the newcomers. People can be added but only in a planned and well co-coordinated manner. Customer Myths Customer requesting software might be a technical group of the same organization, or an outside company requesting software under contract. In many cases, the believes the myths about the software because the responsible may not understand the nature of software development; false expectations must be eliminated at the start. Co manager and practitioners do little to correct misinformation. Myths lead to false expectations by the customer and finally dissatisfaction with the developer. Myth: A general statement of objectives is sufficient to start writing programs - we can fill in the details later. Reality: Poor up-front definition is the major cause of failed software efforts. A formal and detailed description of the information domain, function, performance, interfaces, design constraints and validation criteria is essential. These characteristics can be determined only after thorough communication between customer and developer. Myth: Project requirements continually change, but change can be easily accommodated because software is flexible. Reality: It is true that requirements do change, but the impact of change varies with the time that it is introduced. If serious attention is given to up-front definition, early requests for change can be accommodated. The customer can do the review and recommend modifications with relatively little impact on cost. When changes are requested at the design phase, the cost impact grows rapidly: resources have been committed and a design framework has been established, design modifications means additional cost. Changes in function, performance, interfaces or other characteristics during implementation have a severe impact on cost.

Practitioner's Myths

Myths that are still believed by software practitioners have been encouraged by decades of programming culture. During the early days of software, programming was viewed as an art form. Old ways and attitudes die-hard.

Myth: Once we write a program and get it to work, our job is done. Reality: Someone once said,” The sooner you begin writing code, the longer it will take you to get done”. The industry data indicates that the majority of effort expended on a program will be after the program has been delivered to the customer for the first time.

Myth: Until I get the program running I have no way of assessing its quality. Reality: One of the most effective software quality assurance mechanisms is the formal technical review. These can be undertaken long before the program is running.

Myth: The only deliverable for a successful project is the working program. Reality: A working program is only one of the elements of the project. Other elements include: project plans, requirements specifications, system designs, test specifications, support documentation etc. Documentation forms the foundation for successful development and, more importantly, provides the foundation for the software maintenance task.

• Software Applications Information determinacy refers to the predictable of the order and timing of information. An engineering analysis program accepts data that have a predefine order, execute the analysis algorithm(s) without interruption, and produce resultant data in report or graphical format. It is sometime difficult to develop meaningful generic categories for software application. As software complexity grows, neat compartmentalization disappears. The fallowing software areas indicate the breadth of potential application.

1. System Software: - System Software is a collection of programs written to service other programs. Some System Software (Compiler, editor) processes complex but defined, information structure. Other System Software (Operating system components, drivers) process large undefined data. In both the cases, the system software is characterized by heavy interaction with computer hardware: heavy usage by multiple users, concurrent process scheduling, resource sharing, process management, etc. 2. Real-Time software: -Software that monitor/analyzes/controls real-world events as they occur is called real-time software. Real-time software includes a data gathering component that collects and formats information from an external environment, an analysis component that transforms information as required by the application, a control component that responds to the external environment, and a monitoring component that coordinates all other components so that real-time response can be maintained. 3. Business Software: - Business information processing is the largest single software application area. Applications in this area (payroll, inventory) restructure existing data in a way that facilitates business operations or management decision making. 4. Engineering and Scientific Software: - Engineering and Scientific software has been characterized by “number crunching” algorithms. System simulation, computer-aided design and other interactive applications are some of the examples. 5. Embedded Software: - Embedded software resides in read-only memory and is used to control products and systems for consumer and industrial markets. Embedded software can perform limited functions (keypad control for a microwave oven) or provide significant function and control capability (digital functions in an automobile such as fuel control, dashboard displays, braking systems). 6. Personal Computer Software: - The personal computer software market has grown rapidly over the past decade. Word processing, spreadsheets, computer graphics, multimedia, database management, personal and business financial applications are some of the applications. 7. Artificial Intelligence Software: - Artificial Intelligence software makes use of non numerical algorithm to solve complex problem that are not liable to computation or straightforward analysis. An active area is Expert systems, also known as knowledge-based systems. Other application areas include pattern recognition, game playing and recently artificial neural network has evolved.

• Software Engineering Definitions The need for systematic approaches to development and maintenance of computer software products became apparent in 1960s. During this decade, third generation computing hardware was invented, and the software techniques of multiprogramming and time-sharing were developed. These capabilities provided the technology for implementation of interactive, multiuser, on-line and real-time computing systems. As the computing systems became larger and more complex, it became apparent that the demand for computer software was growing faster than our ability to produce and maintain it. A workshop was held in Garmisch, West Germany, in 1968, to consider the growing problems of software technology. This workshop and the subsequent one held in Rome, Italy, in 1969, stimulated widespread interest in the technical and managerial processes used to develop and maintain computer software. The term “software engineering” was first used in these workshops. Since 1968, the applications of digital computers have become increasingly diverse, complex, and critical to modern society. As a result, the field of software engineering has evolved into technological discipline of considerable importance. According to Boehm, software engineering involves “the practical application of scientific knowledge to the design and construction of computer programs and the associated documentation required to develop, operate, and maintain them”. The IEEE Standard Glossary of Software Engineering terminology defines software engineering as “The systematic approach to the development, operation, maintenance, and retirement of software”. “Software engineering is the technological and managerial discipline concerned with systematic production and maintenance of software products that are developed and modified on time and within cost estimates”. The primary goals of software engineering are to improve the quality of software products and to increase the productivity and job satisfaction of software engineers. • The Software Process Software Process is the total set of software engineering activities necessary to develop and maintain software products. It can be characterized as shown in the figure below. A Common Process Framework is established by defining a small number of framework activities that are applicable to all software projects, regardless of their size and complexity. A number of task sets each a collection of software engineering work tasks, project milestones, software work products and deliverables, and quality assurance points- enable the framework activities to be adapted to the characteristics of the software project and the requirements of the project team.

Finally Umbrella activities- such as software quality assurance, software configuration management, and measurement-overly the process model. Umbrella activities are independent of any framework activity and occur throughout the process.

• Software Process Models The development strategy encompassing all the activities required to define, develop, test, deliver, operate and maintain software product is often referred to as Process Model or Software Engineering Paradigm. Different models emphasize different aspects of the life cycle, and no single model is appropriate for all software products. It is important to define a life-cycle model for each software project because the model provides a basis for controlling the various activities required to develop and maintain a software product. The selection of a process model is based on the nature of the project and application, the tools to be used and the controls and deliverables that are required.

All software development can be characterized as a problem solving loop in which four distinct stages are encountered: status quo, problem definition, technical development, and solution integration. Status quo represents the current state of the process; problem definition identifies the specific problem to be solved; technical development solves the problem through the application of some technology; and solution integration delivers the results to those who requested the solution in the first place.

Regardless of the process model that is chosen for a software project, all of the stages- status quo, problem definition, technical development, and solution integration- exist simultaneously at some level of detail.

I. The Linear Sequential Model Sometimes called the “classic life cycle” or “waterfall model”, the linear sequential model suggests a systematic, sequential approach to the software development that begins at the system level and progresses through analysis, design, coding, testing and maintenance.

Linear sequential model involves the following activities.

System/information engineering: Because software is always part of a larger system, work begins by establishing requirements for all the system elements and then allocating some subset of these requirements to software. This system view is essential when software must interface with other elements such as hardware, people, and databases. System engineering and analysis involves requirements gathering at the system level with a small amount of top-level analysis and design. Information engineering involves requirements gathering at the strategic business level and at the business area level.

Software requirement analysis: The requirements gathering process is intensified and focused specifically on software. To understand the nature of the program to be built, the software engineer must understand the information domain for the software as well as required function, behavior, performance, and interfacing. Requirements for both the system and the software are documented and reviewed with the customer.

Design: Software design is a multi step process that focuses on four distinct attributes of a program: data structure, software architecture, interface representations, procedural detail. The design process translates requirements into a representation of the software that can be assessed for quality before code generation begins. Like requirements, the design is documented and becomes part of the software configuration.

Code generation: The design must be translated into a machine readable form. The code generation step performs this task. If design is performed in a detailed manner, code generation can be accomplished mechanistically.

Testing: Once code has been generated, program testing begins. The testing process focuses on the logical internals of the software, assuring that all statements have been tested, and on the functional externals- that is, conducting tests to uncover errors and ensure that defined input will produce actual results that agree with required results.

Maintenance: Software will undergo change after it is delivered to the customer. Change will occur because errors have been encountered, because the software must be adopted to accommodate changes in its external environment or because the customer requires functional or performance enhancements. Software maintenance reapplies each of the preceding phases to an existing program rather than a new one.

The linear sequential model is the oldest and the most widely used model for software engineering. Some of the problems that may arise when linear sequential model is applied are:

1. Real projects rarely follow the sequential flow that the model proposes. Although the linear model can accommodate iterations, it does so indirectly. As a result, changes can cause confusion as the project team proceeds. 2. It is often difficult for the customer to state all the requirements explicitly. The linear sequential model requires this and has difficulty accommodating the natural uncertainty that exists at the beginning of many projects. 3. The customer must have patience. A working version of the program will not be available until late in the project time-span. A major blunder, if undetected until the working program is reviewed, can be disastrous.

Each of these problems is real. But still the classic life cycle model has a definite and important place in the software engineering work. It provides a template into which methods for analysis, design, coding, testing, and maintenance can be placed. The classic life cycle remains the most widely used process model for software engineering.

II. The Prototyping Model Often, a customer defines a set of general objectives for software but does not identify detailed input, processing or output requirements. In other cases, the developer may be unsure of the efficiency of an algorithm, the adaptability of an operating system, or the form that human machine interaction should take. In these and many other situations, a prototyping model may offer the best approach.

The Prototype model shown below begins with requirement gathering.

Developer and customer meet and define the overall objectives for the software, identify whatever requirements are known and outline the areas where further definition is required. The output is ‘quick design’. A quick design focuses on a representation of those aspects of the software that will be visible to the customer. The quick design leads to the construction of a prototype. The prototype is evaluated by the customer and is used to refine the requirements for the software to be developed. Iteration occurs as the prototype is tuned to satisfy the needs of the customer, at the same time enabling the developer to better understand the needs of the customer. The prototype model serves as a mechanism for identifying software requirements. Both the developer and the customer like this model. Customers get a feel of the actual system and developer gets some idea about the requirements of the customer. Yet prototype model do have disadvantages.

1. The customer sees what appears to a working version of the software unaware of the things like in a hurry to get it working software quality and maintainability had not been considered. When informed that the product must be rebuilt so that high level of quality can be maintained, the customer demands that with a slight modification prototype model can be converted into a working model. Too often, the software development management relents. 2. The developer often makes implementation compromises in order to get a prototype working quickly. An inappropriate operating system or programming language may be used simply because it is available and known; an inefficient algorithm may be implemented simply to demonstrate capability. After sometime, the developer may become familiar with these choices and forget all the reasons why they were inappropriate. The less-than-ideal choice has now become an integral part of the system.

Although problems can occur, prototyping can be an effective model for software engineering. The key is to define the rules at the beginning; that is. The customer and the developer must both agree that the prototype is built to serve as a mechanism for defining requirements. It is then discarded and the actual software is engineered with the aim towards the quality and maintainability.

III. The Incremental Model The incremental model combines elements of the linear sequential model with the iterative nature of the prototyping. The incremental model applies the linear sequences in a staggered fashion as the time progresses as shown in the figure below.

Each linear sequence produces a deliverable “increment” of the software. In incremental model, the increment is a core product in which the requirements are addressed. The core product is used by the customer. As a result of use and evaluation, a plan is developed for the next increment. The plan addresses the modification of the core product to meet the needs of the customer and delivery of additional features and functionality. This process is repeated until the complete product is produced.

The incremental model, like prototyping, is iterative in nature. But unlike prototyping, the incremental model focuses on the delivery of an operational product with each increment. The early versions of the incremental model provide a platform for the user to evaluate the requirements.

Incremental development is useful when staffing is unavailable for the complete implementation by the deadline that has been established for the project. Early increments can be implemented with fewer people. If the core product is well received, then additional staff can be added to implement the next increment. IV. The Spiral Model The Spiral Model is an evolutionary software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of linear sequential model. In Spiral Model, software is developed in a series of incremental releases. During early iterations, the incremental release might be paper model or prototype. During later iterations, increasingly more complete versions of the engineered system are produced.

The spiral model is divided into a number of framework activities, also called task regions. There may be between three and six task regions. Figure below depicts a spiral model that contains six task regions. 1. Customer Communication – tasks required to establish effective communication between developer and customer. 2. Planning – tasks required to define resources, timelines, and other project related information. 3. Risk analysis – tasks required to assess both technical and management risks. 4. Engineering – tasks required to build one or more representations of the application. 5. Construction & Release – tasks required to construct, test, install and provide user support (documentation and training). 6. Customer Evaluation – tasks required to obtain customer feedback based on evaluation of the software representations created during engineering stage and implemented during the installation stage.

Each of the regions is populated by a series of work tasks that are adapted to the characteristics of the project to be undertaken. For small projects, the number of work tasks and their formalities are low. For larger, more critical projects, each task region contains more work tasks that are defined to achieve a higher level of formality.

As this evolutionary process begins, the software engineering team moves around the spiral in a clockwise direction, beginning at the core. The first circuit around the spiral might result in the development of a product specification; subsequent passes around the spiral might be used to develop a prototype and then progressively more sophisticated versions of the software. Each pass through the planning region results in adjustments to the project plan. Cost and schedule are adjusted based on the feedback derived from customer evaluation. In addition, the project manager adjusts the planned number of iterations required to complete the software.

The spiral model is a realistic approach to the development of large scale system and software. Because software evolves as the process progresses, the developer and the customer better understand and react to risks at each evolutionary level. The spiral model maintains the systematic stepwise approach suggested by the classic life cycle, but incorporates it into an iterative framework that more realistically reflects the real world.

But like other models, the spiral model is not a universally accepted model. It may be difficult to convince the customer that the evolutionary approach is controllable. It requires considerable risk assessment expertise, and completely relies on this expertise for success. If a major risk is not uncovered and managed, problems will occur. Finally, the model itself is relatively new and has not been used as widely as sequential model or prototyping model.

V. RAD Model RAD is a linear sequential software development process model that emphasis an extremely short development cycle using a component based construction approach. If the requirements are well understood and defines, and the project scope is constraint, the RAD process enables a development team to create a fully functional system with in very short time period.

One of the conveniences of developing software is that it is not a physical tool that can be lost once it gets developed or manufactured. Codes are used to implement the software and it does not disappear together with the product. We can re-use the code all over again in another software. We just make a little change in the interface to fit the requirement of the client and we have a brand new program. To make our lives even better in developing software, there are tools coming out of the marking that serves as code generators. No need to create complicated codes, we just run the system through our preferences and we have a fully functional program. The idea of reusing codes and tools is what defines another form of Software Development Life Cycle called Rapid Application Development, or RAD. This form of software development constantly refers to the objective. Instead of creating original coding, developers use other tools such as software development kits and other graphic user interfaces to create programs. RAD also relies heavily on the available codes and reuses it to fit the intended program. Since RAD uses GUI, development kits and existing codes, software development will be faster.

The operational development of the software also works like the Prototype version. Instead of planning out and creating a single documentation, developers only have to look at the objective and use it as a “motivation” to create a program. It will be constantly tested and checked as the new “prototype” is released. Developers constantly create screens and show a workflow until it’s approved by users. It is a very simple process since it doesn’t have to use so many original ideas. It’s basically an aggregate of different tools and cleverly using them to create completely different software. RAD focuses more on the visual instead of the coding or software development. Since it already uses tools for generating codes, developers will have more time setting up the GUI of the software rather than focusing on the root structure of the program. The development cycle also enlists the help of the users to make sure the product being developed could match their taste. This will ensure a good user feedback since their ideas was acknowledged and had an actual impact on the product development. RAD reduces stress in creating GUI, coding and structure since it has a remote possibility of being trashed by users.

RAD (rapid application development) is a concept that products can be developed faster and of higher quality through: 1. Gathering requirements using workshops or focus groups 2. Prototyping and early reiterative user testing of designs 3. The re-use of software components 4. A rigidly paced schedule that defers design improvements to the next product version 5. Less formality in reviews and other team communication

Some companies offer products that provide some or all of the tools for RAD software development. (The concept can be applied to hardware development as well.) These products include requirements gathering tools, prototyping tools, computer-aided software engineering tools, language development environments such as those for the Java platform, groupware for communication among development members, and testing tools. RAD usually embraces object-oriented programming methodology, which inherently fosters software re-use. The most popular object-oriented programming languages, C++ and Java, are offered in visual programming packages often described as providing rapid application development.

RAD model has the following phases: Business Modeling The information flow among business functions is defined by answering questions like what information drives the business process, what information is generated, who generates it, where does the information go, who process it and so on.

Data Modeling The information collected from business modeling is refined into a set of data objects (entities) that are needed to support the business. The attributes (character of each entity) are identified and the relation between these data objects (entities) is defined. Process Modeling The data object defined in the data modeling phase are transformed to achieve the information flow necessary to implement a business function. Processing descriptions are created for adding, modifying, deleting or retrieving a data object. Application Generation Automated tools are used to facilitate construction of the software; even they use the 4th GL techniques. Testing and Turn over Many of the programming components have already been tested since RAD emphasis reuse. This reduces overall testing time. But new components must be tested and all interfaces must be fully exercised.

Advantage and Disadvantages RAD reduces the development time and reusability of components help to speed up development. All functions are modularized so it is easy to work with. For large projects RAD require highly skilled engineers in the team. Both end customer and developer should be committed to complete the system in a much abbreviated time frame. If commitment is lacking, RAD will fail. RAD is based on Object Oriented approach and if it is difficult to modularize the project the RAD may not work well.

The traditional software development cycle follows a rigid sequence of steps with a formal sign-off at the completion of each. A complete, detailed requirements analysis is done that attempts to capture the system requirements in a Requirements Specification. Users are forced to “sign-off” on the specification before development proceeds to the next step. This is followed by a complete system design and then development and testing.

But, what if the design phase uncovers requirements that are technically unfeasible, or extremely expensive to implement? What if errors in the design are encountered during the build phase? The elapsed time between the initial analysis and testing is usually a period of several months. What if business requirements or priorities change or the users realize they overlooked critical needs during the analysis phase? These are many of the reasons why software development projects either fail or don’t meet the user’s expectations when delivered.

RAD is a methodology for compressing the analysis, design, build, and test phases into a series of short, iterative development cycles. This has a number of distinct advantages over the traditional sequential development model.RAD projects are typically staffed with small integrated teams comprised of developers, end users, and IT technical resources. Small teams, combined with short iterative development cycles, optimizes speed, unity of vision and purpose, effective informal communication and simple project management.

VI. The V Model The V - model is SDLC model where execution of processes happens in a sequential manner in V-shape. It is also known as Verification and Validation model. V - Model is an extension of the waterfall model and is based on association of a testing phase for each corresponding development stage. This means that for every single phase in the development cycle there is a directly associated testing phase. This is a highly disciplined model and next phase starts only after completion of the previous phase. Under V-Model, the corresponding testing phase of the development phase is planned in parallel. So there are Verification phases on one side of the .V. and Validation phases on the other side. Coding phase joins the two sides of the V-Model. The below figure illustrates the different phases in V-Model of SDLC.

• The left side of the model is Software Development Life Cycle - SDLC • The right side of the model is Software Test Life Cycle - STLC • The entire figure looks like a V, hence the name V - model

Different phases of Software Development Cycle Activities performed in each stage Requirement Gathering stage • Gather as much information as possible about the details & specifications of the desired software from the client. This is nothing but the Requirements gathering stage. Design Stage • Plan the programming language like Java, PHP, .net; database like Oracle, MySQL, etc. Which would be suited for the project, also some high-level functions & architecture. Built Stage • After design stage, it is built stage, that is nothing but actually code the software Test Stage • Next, you test the software to verify that it is built as per the specifications given by the client. Deployment stage • Deploy the application in the respective environment Maintenance stage • Once your system is ready to use, you may require to change the code later on as per customer request

Apart from V model, there are iterative development models, where development is carried in phases, with each phase adding a functionality to the software. Each phase comprises of its independent set of development and testing activities.

Good examples of Development lifecycles following iterative method are Rapid Application Development, Agile Development

There are numerous development life cycle models. Development model selected for a project depends on the aims and goals of that project.

Testing is not a stand-alone activity, and it has to adapt the development model chosen for the project. In any model, testing should performed at all levels i.e. right from requirements until maintenance.

• Process Iteration Change is inevitable in all large software projects. The system requirements change as the business procuring the system responds to external pressures. Management priorities change. As new technologies become available, designs and implementation change. This means that the software process is not a one-off process; rather, the process activities are regularly repeated as the system is reworked in response to change requests. Two process models have been explicitly designed to support process iteration: 1. Incremental Delivery- The software specification, design and implementation are broken down into a series of increments that are each developed in turn. 2. Spiral Development- The development of the system spirals outwards from an initial outline through to the final developed system. The essence of iterative processes is that the specification is developed in conjunction with the software. However, this conflicts with the procurement model of many organizations where the complete system specification is part of the system development contract. In the incremental approach there is no complete system specification until the final increment is specified. This requires a new form of contract, which large customers such as government agencies may find difficult to accommodate.

• Process Activities The four basic process activities of specification, development, validation and evolution are organized differently in different development processes. In the waterfall model, they are organized in sequence, whereas in evolutionary development they are interleaved. How these activities are carried out depends on the type of software, people and organizational structures involved. 1. Software specification A software requirement is defined as a condition to which a system must comply. Software specification or requirements management is the process of understanding and defining what functional and non-functional requirements are required for the system and identifying the constraints on the system’s operation and development. The requirements engineering process results in the production of a software requirements document that is the specification for the system. There are four main phases in the requirements engineering process: Feasibility study- In this study an estimate is made of whether the identified user needs may be satisfied using current software and hardware technologies. The study considers whether the proposed system will be cost-effective from a business point of view and whether it can be developed within existing budgetary constraints. Requirements elicitation and analysis- This is the process of deriving the system requirements through observation of existing systems, discussions with potential users, requirements workshop, storyboarding, etc. Requirements specification- This is the activity of translating the information gathered during the analysis activity into a document that defines a set of requirements. Two types of requirements may be included in this document: user (functional) requirements and system (non-functional) requirements. Requirements validation- It is determined whether the requirements defined are complete. This activity also checks the requirements for consistency. 2. Software design and implementation The implementation phase of software development is the process of converting a system specification into an executable system through the design of system. A software design is a description of the architecture of the software to be implemented, the data which is part of the system, the interfaces between system components and, sometimes, the algorithms used. A contrasting approach can be used by structured methods for design objectives. A structured method includes a design process model, notations to represent the design, report formats, rules and design guidelines. Most these methods represent the system by graphical models and many cases can automatically generate program code from these models. Various competing methods to support object-oriented design were proposed in the 1990s and these were unified to create the Unified Modeling Language (UML) and the associated unified design process.

3. Software validation Software validation or, more generally, verification and validation (V & V) is intended to show that a system conforms to its specification and that the system meets the expectations of the customer buying the system. It involves checking the processes at each stage of the software process. The majority of validation costs are incurred after implementation when the operation of system is tested. The software is tested in the usual three-stage testing process. The system components, the integrated system and finally the entire system are tested. Component defects are generally discovered early in the process and the interface problems during the system integration. The stages in the testing process are: Component (or unit) testing. Individual components are tested to ensure that they operate correctly. Each component is tested independently, without other system components. System testing- The components are integrated to make up the system. This testing process is concerned with finding errors that result from interactions between components and component interface problems. It is also concerned with validating that the system meets its functional and non-functional requirements. Acceptance testing- It is considered a functional testing of system. The system is tested with data supplied by the system customer. Usually, component development and testing are interleaved. Programmers make up their own test data and test the code as it is developed. However in many process model, such as in V-model, Test Driven Development, Extreme Programming, etc., the design of the test cases starts before the implementation phase of development. If an incremental approach to development is used, each increment should be tested as it is developed, with these tests based on the requirements for that increment. 4. Software evolution Software evolution, specifically software maintenance, is the term used in software engineering to refer to the process of developing software initially, then repeatedly updating it for various reasons. The aim of software evolution would be to implement the possible major changes to the system. The existing larger system is never complete and continues to evolve. As it evolves, the complexity of the system will grow. The main objectives of software evolution are ensuring the reliability and flexibility of the system. The costs of maintenance are often several times the initial development costs of software. — Preceding unsigned comment added by 27.97.138.226 (talk) 17:55, 10 April 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 3 external links on Java (software platform). Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20080620065024/http://blog.softwhere.org/archives/196 to http://blog.softwhere.org/archives/196
• Added archive https://web.archive.org/web/20070102132948/http://www.ociweb.com/jnb/jnbJul2003.html to http://www.ociweb.com/jnb/jnbJul2003.html
• Added archive https://web.archive.org/web/20090325195557/http://research.sun.com/techrep/2002/smli_tr-2002-114.pdf to http://research.sun.com/techrep/2002/smli_tr-2002-114.pdf

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 23:20, 19 April 2017 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 2 external links on Java (software platform). Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://www.webcitation.org/6APXEedqA?url=http://virtualschool.edu/objectivec/influenceOnJava.html to http://virtualschool.edu/objectivec/influenceOnJava.html
• Added archive https://web.archive.org/web/20060715022048/http://blogs.sun.com/roller/page/jonathan/200606 to http://blogs.sun.com/roller/page/jonathan/200606

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 23:01, 22 November 2017 (UTC)

External links modified (January 2018)

Hello fellow Wikipedians,

I have just modified 3 external links on Java (software platform). Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20110820081222/http://blogs.oracle.com/java/entry/future_tech_duke to http://blogs.oracle.com/java/entry/future_tech_duke
• Added archive https://web.archive.org/web/20140724212538/http://blogs.computerworld.com/cybercrime-and-hacking/20921/java-security-flaw-yada-yada-yada to http://blogs.computerworld.com/cybercrime-and-hacking/20921/java-security-flaw-yada-yada-yada
• Added archive https://web.archive.org/web/20130409083307/http://threatpost.com/en_us/blogs/nasty-new-java-zero-day-found-exploit-kits-already-have-it-011013 to http://threatpost.com/en_us/blogs/nasty-new-java-zero-day-found-exploit-kits-already-have-it-011013

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 07:52, 21 January 2018 (UTC)

The English in this article is atrocious

Regarding Oracle, it distributes Java 8, and also makes available e.g. Java 11, a currently supported long-term support (LTS) version, released on September 25, 2018. Oracle (and others) "highly recommend that you uninstall older versions of Java" than Java 8, because of serious risks due to unresolved security issues.

This article is littered with sentences like that. A major cleanup is in order. --Puzzledvegetable^{Is it teatime already?} 18:35, 25 June 2021 (UTC)

"Jusched" listed at Redirects for discussion

A discussion is taking place to address the redirect Jusched. The discussion will occur at Wikipedia:Redirects for discussion/Log/2021 August 26#Jusched until a consensus is reached, and readers of this page are welcome to contribute to the discussion. ~~~~
User:1234qwer1234qwer4 (talk) 20:00, 26 August 2021 (UTC)

Java Runtime Environment page redirect to the section with the same name misleads the readers

A page [Java Runtime Environment] redirects to this article, to the section with the name "Java Runtime Environment". However, the section is not simple for a person who is not familiar with the matter already.

I propose to rewrite the section. I don't wish to remove all the details which are discussed there now. However, they seem to be extra to the sub-topic "Java Runtime Environment". I'd propose to replace (or precede) existing text with more general description, which is about all JREs, not only made by Oracle (as specified in existing section "Java Runtime Environment").

The proposed text:

Java Runtime Environment

A Java runtime environment (JRE) is a collection of software components used to run Java applications. It includes Java virtual machine (JVM), Java class libraries, and Java class loader.

The JRE is a part of the Java development kit (JDK), which is used for developing Java software. The JRE provides programming tools and deployment technologies, while the JVM executes Java programs.

The JRE acts as an intermediary between the Java program and the underlying operating system, allowing the program to access the resources of the OS and run on various platforms. Philip Torchinsky (talk) 18:40, 1 February 2023 (UTC)