|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
[Nov 15, 2004] Smalltalk Tidbits, Industry Rants cargo cult coding practices
Laurent Bossavit explains the notion of "Cargo Cult" programming - the example being setting a temporary variable to null (i.e., one that is going out of scope)
You may object that the setting-to-null superstition is totally harmless. So is throwing salt over your shoulder. While this may be true of one particular superstition, I would be particularly concerned about a team which had many such habits, just like you wouldn't want to trust much of importance your batty old aunt who avoids stepping on cracks, stays home on Fridays, crosses herself on seeing a black cat, but always sends you candy for Christmas.
What superstitious coding practices does your group have?
Comments
null helps GC yes? no? [john mcintosh] November 15, 2004 19:23:32 EST
I once had a fellow phone me from Hong Kong who explained a performance problem they were having. Seems they at the end of each method, and in each "destroy" method for a class (used to to destroy instances), they would set all the variables to NULL. The best was of course iterating over thousands of array elements, setting them to NULL since they felt this was helping the GC find NULL (garbaged) variables faster. Once they stopped doing this why windows just snapped closed....
Empty Java constructor [Jason Dufair] November 16, 2004 10:08:33 EST
I'm on a team doing Java right now. I see a lot of empty Java constructors. Being a Smalltalker making a living doing Java, I figured they must be there for a reason. Come to find out an empty constructor just calls the super's constructor. As if it weren't there in the first place. Whee!
[PDF] Cargo Cults in Java by Gordon Fletcher University of Salford
This paper is a personal account of my experience of teaching Java programming to undergraduate and postgraduate students. These students enter their respective subjects with no previous Java programming knowledge. However, the undergraduate students have previous experience with Visual Basic programming. In contrast, the postgraduate students are enrolled in a “conversion” course which, in most cases, means that they were unfamiliar with any form of programming language or, in some cases, some core information technology skills. Irrespective of these differences, I have witnessed how both groups independently develop, what can be described as, a trade based culture with similarities to ‘cargo cults’ around the Java language. This anthropological term provides a useful terms of reference as the focus of programming activity for many students increasingly centres upon the imitation of code gathered from the lecturer or, in some cases, each other. This is particularly evident as project deadlines approach. In extreme examples of this cargo cult fever, students will discard potentially strong project developments that incorporate many features of good software design in favour of inelegant and cobbled together code on the single criteria of better functionality.In this paper I use the concept of the cargo cult to frame the differing expectations surrounding “learning Java” that are held by students and their lecturer. I draw upon my own observations and experiences as the teacher in these learning environments and upon feedback from my most recent cohort of undergraduate students undertaking an BSc(Hons) programme within a UK university. The student feedback is drawn from a questionnaire containing six questions relating to their experiences and expectations regarding a Java programming subject. The definition and description of the cargo cult is also used to consider how this relationship can be established in a way that encourages positive learning outcomes through the obligations and reciprocation associated with gifts – in this case, clearly labeled gifts of code. The cargo cult and the erroneous form of thinking associated with it provide a useful framework for understanding the teaching and learning environment in which I taught Java. In this way the interactions and motivation of students and the lecturers who ultimately share the common goal of obtaining their academic success can be scrutinized with the aim of improving this experience for all those involved. The cargo cult is not, however, ‘simply’ an anachronistic analogy drawn from social anthropology. Cargo cult thinking has been identified within contemporary culture as readily as tribal cultures and with equal significance (Hirsch 2002; Cringely 2001, Fitzgerald 1999; Feynman 1974).
2. Cargo Cult Thinking
It is important to acknowledge that cargo cult thinking is not necessarily the ‘wrong’ way of thinking or that this paper seeks to castigate students’ study practices. Cargo cult thinking is based, in part, on conclusions drawn from only partially observed phenomena. In many respects this paper is a reflexive exercise regarding my own teaching practices and an examination of the ways in which cargo cult thinking can be employed to achieve positive learning outcomes. Nonetheless, despite this acknowledgement, the actions of cargo cult followers are based upon a “fallacious reasoning” of cause and effect. This could be summarized in the context of Java programming as the assumption that if I, as a student, write my code like you, the lecturer, do, or use your code as much as possible, I will be a programmer like you and this is what is required for me to do well - or at least pass - this subject. However, as teachers of Java it is necessary to acknowledge the – perhaps dormant – presence of this attitude and to consequently offer offhand code examples with extreme caution. I have repeatedly spotted examples of my own code embedded within students’ projects. Although the code may originally have been offered as a quick and incomplete example of a concept or a particular line of thinking it can too readily become the cornerstone of larger scale classes without modification. It is perhaps, then unsurprising, that the cargo cult attitude does, develop among students when they are first learning a programming language and the concepts of programming. The consequence of pursuing this belief unchecked parallels the effects of learning in a “Java for Dummies” manner. Deeper, conceptual understanding and problem-solving techniques remain undeveloped and students are left able only to imitate the step-by-step procedures outlined by the textbook. This step-by-step form of explicit instruction discourages exploration and discourages students from appreciating the learning that is occurring when they disentangle java compiler errors. This is perhaps one of the most revealing differences between students and lecturers. While experienced programmers use compiler errors, new programmers will see the errors as “just one more thing” getting in the way of a successfully executing application. This suggests a lack of awareness that programming is not synonymous with writing code. The consuming focus in the majority of undergraduate and postgraduate assessment projects is upon pursuing and obtaining functionality in their code to the detriment of the user interface, clear documentation, class structures, code reusability, extensibility or reliability.
INTERNALMEMOS.COM - Internet's largest collection of corporate memos and internal communication Sun Microsystems The Java Problem
The Java Problem
Author: Julian S. Taylor
Reviewed by: Steve Talley, Mark Carlson, Henry Knapp, Willy (Waikwan) Hui, Eugene Krivopaltsev, Peter Madany, Michael Boucher
Executive Summary
While the Java language provides many advantages over C and C++, its implementation on Solaris presents barriers to the delivery of reliable applications. These barriers prevent general acceptance of Java for production software within Sun. A review of the problem indicates that these issues are not inherent to Java but instead represent implementation oversights and inconsistencies common to projects which do not communicate effectively with partners and users.
Within Sun, the institutional mechanism for promoting this sort of communication between partners is the System Architecture Council codified in the Software Development Framework (SDF). We propose that the process of releasing our Java implementation will benefit from conformance with the SDF.
Introduction
This document details the difficulties that keep our Solaris Java implementation from being practical for the development of common software applications. It represents a consensus of several senior engineers within Sun Microsystems. We believe that our Java implementation is inappropriate for a large number of categories of software application. We do not believe these flaws are inherent in the Java platform but that they relate to difficulties in our Solaris implementation.
We all agree that the Java language offers many advantages over the alternatives. We would generally prefer to deploy our applications in Java but the implementation provided for Solaris is inadequate to the task of producing supportable and reliable products.
Our experience in filing bugs against Java has been to see them rapidly closed as "will not fix". 22% of accepted non-duplicate bugs against base Java are closed in this way as opposed to 7% for C++. Key examples include:
4246106 Large virtual memory consumption of JVM
4374713 Anonymous inner classes have incompatible serialization
4380663 Multiple bottlenecks in the JVM
4407856 RMI secure transport provider doesn't timeout SSL sessions
4460368 For jdk1.4, JTable.setCellSelectionEnabled() does not work
4460382 For Jdk1.4, the table editors for JTable do not work.
4433962 JDK1.3 HotSpot JVM crashes Sun Management Center Console
4463644 Calculation of JTable's height is different for jdk1.2 and jdk1.4
4475676 [under jdk1.3.1, new JFrame launch causes jumping]
In personal conversations with Java engineers and managers, it appears that Solaris is not a priority and the resource issues are not viewed as serious. Attempts to discuss this have not been productive and the message we hear routinely from Java engineering is that new features are key and improvements to the foundation are secondary. This is mentioned only to make it clear that other avenues for change have been explored but without success. Here we seek to briefly present the problem and recommend a solution.
Defining the Java Problem
These are the problems we have observed which we believe indicate the need for an improved implementation and a modified approach.
1. The support model seems flawed
Since Java is not a self-contained binary, every Java program depends fundamentally upon the installed Java Runtime Environment (JRE). If that JRE is broken, correction and relief is required. This sort of relief needs to happen in a timely manner and needs to fix only the problem without the likelihood of introducing additional bugs. Java Software does not provide such relief.
Java packages are released (re-released) every four or five months, introducing bug fixes and new features and new bugs with each release. These releases are upgrading packages which remove all trace of the prior installed packages and cannot be down-graded in the event of an error. The standard release taxonomy used by the Architecture Review Committees (ARCs) was developed for use by Solaris and our other mission-critical software products to help solve these and many other problems.
It is impractical for a project based on Java to correct bugs in the Java implementation. Java Software corrects bugs only by releasing an entire new version. For that reason, projects seek to deliver their own copy of Java so they can maintain it without fear of a future upgrade. Outside vendors, such as TogetherJ, specify a particular release of Java for their product. The customer must locate that release and install it. If a future product seeks to use a different version, that version has to be installed side-by-side with the prior version or TogetherJ may no longer function.
The ARCs commonly see project submittals requesting permission to ship their own version of Java. The ARCs have been routinely forbidding projects to do this even though they are aware of specific cases wherein interfaces or their underlying behaviors have changed incompatibly across minor releases.
The threat of losing the ability to directly support such a substantial part of their product has inhibited projects from choosing Java as their implementation language and caused widely-discussed problems for customers of projects that have used Java. Consider that the Java language supports rapid development, simple testing and access to a wide variety of platforms. Why are the shelves at CompUSA (a Linux friendly store) not crammed with W32/Linux/etc offerings written in Java? As it stands client-side Java remains primarily a web language partly because the Netscape platform runs Java 1.1.5 and has not changed for years. It is buggy but very stable.
This indicates that Java must strictly enforce backward compatibility across minor releases and must adhere to Sun release taxonomy for the identification of releases. Further, existing releases must support some sort of remedy akin to a patch so that existing installations can be corrected through existing methods.
2. The JRE is very large.
The JRE is significantly larger than comparable runtime environments when considering resident set size (memory dedicated to this specific program). It has been seen to grow to as much as 900M. This has a drastic effect on both performance and resource usage. It also means that multiple JREs present critical resource constraints on the servers for such thin-client systems as SunRays. Typical resident set requirements for Java2 programs include:
Hello World 9M
SMC Server 38M
SLVM GUI 60M
Component Manager 160M
TogetherJ 300 - 900M
The largest program in that list is TogetherJ. From the standpoint of resource requirements, TogetherJ does much of what Rational Rose does but Rational Rose appears to function in less than 250M. Startup time is effected as well. For example, on an Ultra10 TogetherJ requires 5 minutes to load and start. SMC, Sun's flagship system admin console, takes between one and two minutes to reach the point that it can be used.
Some of this problem appears to relate to the JRE. We do not have the time or money to conduct a serious side-by-side study of Java vs other languages and are therefore calling upon our personal experiences with Java development. The fact that these experiences are hard to quantify forces us to try to support the validity of this concern through existing research.
A study performed by an outside team appears to indicate a rough parity in performance between Java and a common implementation of another OO language called Python (see IEEE Computing, October 2000, "An Empirical Comparison of Seven Programming Languages" by Lutz Prechelt of the University of Karlsruhe). Both platforms are Object Oriented, support web applications, serialization, internet connections and native interfaces. The key difference is that Python is a scripting language. This means there is no compilation to byte code so the Python runtime environment has to do two things in addition to what the Java runtime environment does. It has to perform syntax checks and it must parse the ascii text provided by the programmer. Both of those tasks are performed at compile time by Java and so that capability does not have to be in the JRE.
Given this data, it appears that the JRE can actually be simpler than the Python RE since Java does at least some of this work at compile time. The example above of "Hello World" is a good method for getting an idea of the minimum support code required at runtime. This support code includes garbage collector, byte code interpreter, exception processor and the like. Hello World written in Java2 requires 9M for this most basic support infrastructure. By comparison, this is slightly larger than automountd on Solaris8. The Python runtime required to execute Hello World is roughly 1.6M.
Further examples of what is possible include the compiling OO languages Eiffel and Sather which fit their garbage collector, exception processor and other infrastructure into roughly 400K of resident set. While the Java VM (as demonstrated above) grows rapidly as more complex code is executed, the Python VM grows quite slowly. Indeed, an inventory control program written entirely in Python having a SQL database, a curses UI, and network connectivity requires only 1.7M of resident set. This seems to indicate that the resident set requirements of the JRE could be reduced by at least 80%.
Imagine what happens if our current implementation of Java were ubiquitous and all 150 users on a SunRay server were running one and only one Java program equivalent to Component Manager above. The twenty-four gigabytes of RAM the server would have to supply exclusively to these users is well beyond the typical configuration. RAM is cheap but performance is what we sell, all customers on that SunRay server would see significant performance degradation even with the maximum amount of RAM installed as all other processes were forced to reside on swap.
The resident set size required by the JRE makes it impractical to run Java in an initial Solaris install environment. It is impractical to run it as a non-terminating daemon. A Java daemon could be started from inetd run long enough to do its job and then quit but the rpc protocol required to pass the socket port to the daemon is very complex and not Java-friendly. Java applications cannot be executed at boot time since the loading of the VM introduces an unacceptable performance degradation. If the Java runtime were as small as that of Python, it is likely that the Java daemon would become popular and could provide basic services to applications written in any number of languages.
3. Extensions do not support modularity.
As new extensions are introduced, they are released separately under their own names and distributed generally. Each one may go through several revisions as separate modules. At some point, they are then folded into base Java, tying base Java's version to the versions of dozens of smaller yet distinct functionalities. These functionalities are then restricted to a draconian backward-compatibility rule since once folded in, they are no longer selectable modules. Examples include modules that used to be called Swing, RTI, IDL, JSSE and JAAS. These are all good things that should be part of Java. Our concern is that these are not separable modules which can evolve as requirements change.
The Java system for evolving the interface (deprecation) does not serve production software very well. Once the interface disappears, the product just breaks. If the Java base were simpler and the more advanced features (those most likely to be deprecated) were delivered as versioned modules, it would be possible for a commercial product to retain it's older modules on the system and survive a large number of Java upgrades.
Production quality programs written in Java, like TogetherJ, indicate a specific Java version which must be installed before the program is run. If another program is installed, requiring a higher Java version, the user may be forced to decide which program stays and which goes away. Alternatively, the other Java version could be installed to a different base directory but this requires considerable sophistication on the part of the user, complicates administration and violates the ARC big rule that common software must be shared.
4. It is not backward-compatible across minor releases.
Among the various incompatibilities across minor releases are:
a) In JDK 1.1 Class.fields() returns only public variables. In 1.2, protected and private variables are returned.
b) Swing table sizing calculation changed from Java 1.3 to 1.4.
c) Swing JFrame launch behavior changed significantly from Java 1.2.2 to Java 1.3.1.
Each of these examples is simple, but they demonstrate the general problem that people cannot program for a particular release of Java and expect that their programs will continue to run. This is a serious problem now, but has the potential to become a show-stopper as technology such as auto-update advances.
What is perhaps more important is that the perception of Java as an unstable platform is widespread. This perception is restated with every Java-based project to come to ARC. Within Sun, Java is not viewed as a satisfactory language for the construction of commercial applications. This perception and the record require addressing.
The Java Problem is Recognized Internally
That our Java implementation is perceived as inappropriate for many uses is supported by internal documents and policies. For example:
1. SOESC AI - 092501.2 Java Dependencies for Deployment
In this document provided to SOESC, John Perry describes the concerns regarding the Solaris "JVM dependencies for deployment". Following is an excerpt:
-------
- Large footprint of applications when run on Solaris. A simple application ("hello world" type) has a total footprint of 35-40 megs on Solaris 9 (build 48, using Java 1.4 build 82) on both Intel and Sparc machines. Sparc machines, by far, have a much higher resident footprint then Intel machines (~30 megs, compared to ~11 megs). The same program run on a Windows machine has a footprint of ~5 megs, resident footprint being ~3.5 megs
- Slow start up times prevents Java applications from being started while Solaris is booting up and during mini-root time. This requires applications which are written in Java to have some kind of mechanism to start-up after the OS has been fully started.
- Instability of Native code (JNI) which can cause the entire VM to crash.
-------
2. Teams Are Looking for Options
The CIMOM (supporting WBEM) is a Java daemon. It initially occupies around 40M of RSS but grows from there. In order to address this problem, at least one Sun Engineer, Peter Madany, has been doing research to determine Java daemon memory utilization when running on a currently unsupported J2ME VM on Solaris. In other words, we are looking into demonstrating that resource exhaustion on Solaris Servers could be avoided by using some of the techniques used in an edition of Java intended for very small systems.
3. New Projects Explain Why They Are Not Using Java
Quoting from the recently submitted Nile case (SARC/2001/617) now under review:
-------
These libraries should be commercial implementations and must be in native platform code (ie not Java or Perl). Native code is a requirement because one of the core requirements for the proxy is for minimum impact on the target host. Java has too large a footprint (both memory and disk image) and may not be installed on the customer's host.
-------
4. ARCs Include the Java Problem in Rejection Reasoning
Quoting from the recently rejected SunMC PMA case (LSARC/2000/457):
-------
The CLI interpreter is implemented in Java, and the overhead of starting a JVM for each command execution is prohibitive. At least one of the votes to reject was related to this inappropriate use of Java. The Solaris implementation of Java is slow and very large. While this project did not provide a measurement of resident set for their CLI, the minimum RSS for the JVM is known to be 9MB and the typical RSS for a similar Java program is 30 to 40MB, and takes up to 15 seconds to start. The project team admitted in the review that this CLI may be used on a daily basis. For such a CLI, the delays and resource requirements of the Solaris Java implementation are unacceptable.
-------
5. Customers and Field Engineers Are Noticing the Problem
Following is an excerpt from Kevin Tay's e-mail to three Java aliases regarding a customer installation of a third-party product written in Java called Vitria. We see typical very large RSS numbers compared to a WinNT implementation combined with increased resource usage from Solaris7 to Solaris8:
-------
Customer said they have something like 450+ container servers and 80+ automator server for the Vitria system. So the estimation for the hardware RAM is around 9GB for USII machine and 14-15GB for the USIII machine. Questions:
1. Why is Sun systems using so much more memory?
2. Why is the UltraSPARC III/Solaris 8 system using a lot more memory than a UltraSPARC II/Solaris 7 system (with every other thing being equal)?
3. How can I reduce the memory utilization of the UltraSPARC III system?
-------
NOTE: The response to this e-mail was to suggest moving to a different build of Java 1.2.2 since the indicated build on Solaris 8 had a known bug; it should be noted, however, that the 9GB memory footprint for Solaris7 is still unusually large.
6. Close Call in Solaris9
Bug ID 4526853 describes a bug in Core Java which used to be an external module called JSSE. Among other products, PatchPro and PatchManager depend on the JSSE. As long as the module could be used, the JSSE interface could be trusted to remain stable despite extensive changes in core Java. Now the Java architecture makes it impossible to use the module. This bug in core Java completely disables PatchPro and PatchManager. It was introduced in build 83 of Java 1.4. It was detected and corrected before the final build of Solaris9. If it had not been detected before the final build, it would have shipped with Solaris9 FCS.
For those products that depend upon JSSE and operate on multiple OSs, there would have been no recourse except to deliver with their product an entire new Java distribution. This distribution would have to upgrade the existing Java installation. The fact that various products depend upon specific versions would mean that such an upgrade would carry the risk of breaking other Java-based software on the target system.
Correcting the Java Problem
We strongly recommend that management require Java to conform to the Software Development Framework especially from the standpoint of ARCreview. We believe that the next release of the Sun Java implementation should be brought to ARC while still in the prototype phase. Both PSARC and LSARC have dealt with the Java issues peripherally, recognizing numerous problems but unable to effect change in the underlying source of the difficulties - namely Java. By bringing the Sun Java implementation through ARC, these issues can be resolved.See also Slashdot Even Sun Can't Use Java
Re:InternalMemos is notorious for hoaxes (Score:1)
by denny_d (454663) on Sunday February 09, @11:58AM (#5264814)Glad to read someone's questioning the source of the memo. That said, I'm constantly bumping against java apps that consume all system memory. Are there specs. to be found on the HelloWorld example?... [ Parent ] Re:InternalMemos is notorious for hoaxes (Score:5, Informative)
by MikeFM (12491) on Sunday February 09, @01:49PM (#5265480)
(http://kavlon.org/ | Last Journal: Friday March 21, @02:10PM)[email protected] is the address Google came up with for me. Not sure if it's the right one. Seems close enough though.
Since when are memos technically correct? You must work at a lot geekier place than I have. Not that I think InternalMemos isn't notorious for hoaxes.
I wouldn't hold out for Sun to switch from Java to Python either but I really wish they would. Java blows. Python is easier to develop (fewer required tools etc) and runs a lot better under both Linux and Windows. Python (with wxPython) produces nicer looking more functional gui programs to.
|
Re:InternalMemos is notorious for hoaxes (Score:2)
by RenQuanta (3274) on Sunday February 09, @02:11PM (#5265630) |
Why is comparison with Python amusing? I've been using Python for
three and a half years now, and everything that the memo states about
Python is true and accurate:
I've used all of those aspects of Python: OO, serialization, web
application support, internet connections, and native interfaces. I've
also used multi-threading, and GUI interfaces (PyGTK, and built-in PyTk).
I have yet to find a problem that couldn't be easily solved with Python.
It makes for rapid development and robust solutions. |
|
Re:Hypocrisy? (Score:4, Insightful) by Jahf (21968) on Sunday February 09, @12:37PM (#5264696) (Last Journal: Wednesday March 24, @01:13PM) |
| I still work for Sun and have never seen anything like this memo.
Java is still used daily for internal projects, still hyped strong and
developed strong, and I've never seen a Sun person try and dissuade
another from using it. If the memo is real, then it's being kept in a very small group. If it's fake, they did a good job with the language and examples. |
|
Sun employee: memo is on target (Score:5, Interesting)
by joelparker (586428) <[email protected]> on Sunday February 09, @08:56PM (#5267630) (http://www.school.net/) |
| You haven't seen it? Is it possible you haven't looked for it?
I am a former Sun employee and I wrote these kinds of memos. Specifically, I wrote that Java was unsuitable for Sun's own web development projects, and that this represented a serious problem in terms of missed opportunities to improve our software and for our public relations and marketing. The memo may be a fake, but it's right on target. I especially agree with the problem of internal tech support for critical bug fixes. I worked on several projects that were a nightmare due to subtle bugs in Java's HTML and XML classes. In each case, the bugs were easy to fix: a few lines of code, changing private methods to protected methods, etc. The response from Sun support? "Will not fix." So I had to rewrite the classes-- basically rederiving the entire Java HTML+XML parsing tree-- which stuck the customer using my custom code. Talk about a bad upgrade path! There were many, many examples of this. As a result, I deployed many projects using Perl on Linux instead of Java on Solaris, and I wrote internal memos like the one in this article. All that said, the Java engineers were some of the smartest, nicest people I've ever had the pleasure of working with. I have a lot of confidence in them, and each Java release gets substantially better and faster. The problem IMHO is not the engineers, but the corporate culture that misses opportunities to learn from employee projects. The Sun engineers and internal developers can really do some amazing things, if McNealy and Zander could start prioritizing Java inside Sun, and start funding rapid-turnaround tech support for employee programmers. Cheers, |
|
Re:Hypocrisy? (Score:5, Insightful) by g4dget (579145) on Sunday February 09, @11:00AM (#5264134) |
| I think the primary interest here is "server side Java", doing
heavy lifting business applications. Currently Java/J2EE is in a
competition with For server-side apps, it makes no difference whether Microsoft bundles the JRE or not--anybody putting together a bunch of servers is going to install the latest JRE directly from Sun anyway. In fact, while Java is a decent language for server-side development (and that's pretty much the only thing it's really good at), it's ironic that its cross-platform features in particular are largely irrelevant there: for many other reasons, any reasonable place is going to have a homogeneous server environment for individual web apps, and re-compiling for that server environment is a tiny part of deployment. So, something like GNU gcj, which requires recompilation for each target platform, may well be the better choice than Sun's bloated JRE: while you don't get universal byte code deployment, which you don't need, gcj binaries start up much faster and consume less resources, which may be more important on your server. |
| Re:Hypocrisy? (Score:5,
Insightful) by Zeinfeld (263942) on Sunday February 09, @11:01AM (#5264136) (http://slashdot.org/ | Last Journal: Monday October 07, @06:09PM) |
| This smells bad. Sun have been
forcing the monopoly thing down microsofts
throat for so long, and now there they are
victim of themselves again.
The note is certain to be used by Microsoft in their appeal against the Java injunction. In particular the points about Java code being tied to a particular runtime completely negates Sun's claims about the need to distribute in the O/S base. Clearly that is not going to help much since Sun have no clue about dependency management. Consider the following thought experiment. Microsoft distribute 30Mb of Java 1.3 with XP. Then Sun upgrade to 1.4, what does Microsoft do? Do they distribute 1.4 on the new O/S versions only, add it to the current release of XP or put it on instant update. None of these work. The instant update option will break existing java applets on the system. Mixed versions of java will mean that consumers buying a Java based progam will not be able to rely on the release number of XP to decide whether the program works on their machine. Waiting till the next O/S version is released will result in a lawsuit from sun. The note shows clear similarities to the early articles on C# explaining the difference in approach between Java and dotNet. If the Java lobby was not so convinced that Java was the end of program language design they would have realised their significance. To give one example, the version incompatibility problem is known to Windows developers as 'DLLHell'. My company uses Java for a lot of
projects. I would not be suprised however if
we didn't end up on Unfortunately Sun don't have a level 5 leader in charge. They have an egotistical idiot who is concentrated like a laser on another companies business instead of his own.Antics like those of McNeally and Ellison play well in the press but measured by the success of the companies stock price leaders like Jack Welch or Lee Iaccoca don't do as well as their PR would have it. Iaccoca may have saved Chrysler (it might also have been the government loans) but once he started concentrating his energies on being a folk hero Chrysler's performance went back down the tubes. Similarly Jack Welch's performance does not look that hot if you look at the growth in GE earnings rather than the stock price - which is certain to shrink as GE returns to its old P/E multiple. One of the things a level 5 leader does is to encourage comment. The memo only says what others outside Sun have been saying for eight years. My take on the Sun/Microsoft Java war is based on a lot of time working in standards groups with both groups of engineers. I think that the Microsoft engineers thought they could improve Java and got frustrated because the Sun engineers behaved - well like Microsoft engineers sometimes do. Of course this will all be rationalised away. Of course it was all the fault of the Redmond club's evil schemes. Nobody outside Sun has any ideas of any value and Sun's JCM is genuinely open and not a proprietary farce. |
|
|
Desperate measure (Score:5, Insightful) by Knacklappen (526643) <[email protected]> on Sunday February 09, @10:20AM (#5263921) (Last Journal: Wednesday June 30, @04:24PM) |
| Reads to me like a memo that has intentionally leaked out into the
open, trying to force Sun Management to act. Software Development Dept
is clearly unhappy with the Solaris implementation of JRE and therefore
stops all use of it, until is has been fixed. While the Java Dept does
not seem to have too much hurry to do that (majority of cases closed -
"will not fix". What would you do in your own line organization, when you are the boss of one department and the boss of the other department just gives you the finger? And your superior is unable/unwilling to solve the conflict? You write a flaming mail to your superior's superior, threaten to withdraw any support for the platform your company is famous for and leak the memo into the open to get public support. This, of course, has to be done nicely so that no-one can blame you directly for it. |
|
Re:Smells of a Fake (Score:5, Informative) by tom's a-cold (253195) on Sunday February 09, @01:51PM (#5265102) (http://slashdot.org/) |
Anyone that compares a scripting languate (python) to a full programming language that also as a VM has no clue. a scripting language has minimal overhead memory requirements because it does not have much of a memory management job to do.Your remarks about Python, and scripting languages in general, are not borne out by my own first-hand experience as a designer and developer. First, you make it sound like, in some sense, scripting languages are not as complete as "real" programming languages. And your comments about memory management make even less sense-- any language with OO features (and many without) are going to have to do dynamic allocation-- how else are object references going to be dealt with?-- and that means that they're going to have to deal with memory-management issues. And if you think that all scripts are like little baby shellscripts, you haven't been around much. I've developed medium-sized apps in Python and in Perl (on the order of 50K lines of executable code), and much bigger apps in Java. Python is semantically rich enough, and in most instances fast enough, to do anything that Java can do, and almost always with shorter, more readable code. The same can be said for Perl (though it requires more discipline to achieve the readability), and probably also Ruby and Scheme. From a software engineering point of view, I'd be happiest coding the whole app in Jython (the Python variant that compiles down to Java bytecodes), then recoding the hotspots in Java, or in some even lower-level language. Developers, even smart ones, usually guess wrong about what to optimize, so deferring tuning until you observe the working system is usually a good idea. Exceptions would be embedded and hard-realtime systems. Almost every business app I've seen is neither of these. This in no way eliminates the need to design your app before coding it, BTW, contrary to what some bozos who once read the blurb on the back of an XP how-to book might have you believe. When I did a demo of one Python-based app that I developed, my client was willing to accept a performance hit for the sake of better maintainability. When I benched its performance on one content-mangement task, it clocked in at 100 times faster than its C++ predecessor. Now obviously, a very clever C++ crew could have done a lot better than that. But in the real world, everyone's in a hurry and don't always choose the cleanest implementation. And when language features are too low-level, developers waste a lot of time reinventing "infrastructure." In this instance, they not only reinvented, but did it much more poorly than the developers of Python did. |
|
Re:Not too surprised (Score:4, Interesting) by Fjord (99230) on Sunday February 09, @11:01PM (#5268109) (http://slashdot.org/ | Last Journal: Tuesday December 16, @06:30PM) |
| There's a difference in learning CS fundamentals and aligning your
career. The fact is that a senior J2EE developer isn't considered a
senior I would get worried about Java as a career yet though. I just recently switched workplaces as a J2EE architect. At least in my town (Jacksonville), and accorind to the recruiting firms I talked to, there is very little else going on except J2EE. I can definitely see Java being the COBOL: great now, but antiquated later. More to the topic at hand, I don't see client side Java getting better anytime soon, because Sun already lost a lot on that side while gained a lot on the J2EE side. Future releases will be more geared towards long uptime high memory applications more than short small ones. |
|
Re:... nothing new under the sun (Score:4, Interesting)
by DarthWiggle (537589) <[email protected] minus city> on Sunday February 09, @11:05AM (#5264152) (Last Journal: Tuesday February 04, @09:22PM) |
| Why in God's name is this modded troll? Have we offended the
slathering hordes of Java devotees? Lemme tell all of you something,
when I was laid-off from a position, I went to interview with two shops,
both with a heavy Java focus, and roughly equivalent in their focus,
style, and clients. I didn't get a job with the first. But with the
second, I was given some very good advice: Talk a lot about J2EE, Beans,
and a bunch of other buzzwords, a few of which I had never heard of.
"Doesn't matter if you don't know, man, just throw the words in. That's
all they care about." Got the job. Java is so much about a culture and not a technology that it's disgusting. And it's a pity too, because all the PRINCIPLES of Java (portability through the VM, objectification, etc.) are so good that Microsoft took them to build Hell, I think Java is a great language. It concerns me that it takes seventeen steps to accomplish something as basic as opening a database connection, grabbing some results, and outputting them into an HTML stream (and seventeen may be generous). But, it's a very straightforward language, very teachable because it's so logical. But too much of the culture is fluff. Why is it that Sun doesn't focus on point releases that improve performance but instead focuses on getin gthe newest buzzword, uh, "feature" out the door? Why did they invent something called Java2 which is, IIRC, just Java 1.3? Because they're more concerned about IMAGE than about getting their product - which is great in principle - in a usable state. But let's talk substantively. I've developed large scale server-side applications in Java, C, C++, and - on the web-app side - PHP, Cold Fusion, and ASP. The slowest of those was, almost without exception, Java. Java took the most coding to do a basic task, and Java was BY FAR the most difficult to package, deploy, and deliver to my customers. That's a real pity, because I was about 90% certain that our customer's architecture didn't really matter if we were playing with Java. Upgrading those old Dell NT servers to IBM? No problem. We'll just move the app over, and it should run without a hitch. But, lord have mercy, it ran slowly. To top it all off, here's some advice I received from a Java-guru at another company. I was griping about how slow Java was, and he said to me, "Oh, everybody knows it's slow. But why worry? Hardware's getting faster every day. True, 2ms is half the speed of 1ms, but who's gonna notice?" I almost fell off my chair. It's that sort of laziness that makes my skin crawl. Look, I love Java. I want it to succeed. It's a brilliant idea: an utterly cross-platform language whose apps run without regard to the hardware and OS under them. But it's a seriously flawed masterpiece. (The funny thing is, I was just going to write "Why was this modded troll? But then my post bloated... kinda like how you go to write "Hello World" in Java and... ok, ok, nevermind.) |
|
Re:From the article... (Score:5, Insightful) by The Mayor (6048) on Sunday February 09, @11:08AM (#5264167) (http://www.bluelotussoftware.com/) |
It has always bugged you that Java had no good mechanism to compile
simple expressions on-the-fly? Here are a few options for you:
Performance isn't great, but reports have indicated that Jython is about 75% of the performance (near the end of the article...search for the word "performance") [oreilly.com] of CPython. It's slower than Java code of the same type. But, hey, if you wanted speed you wouldn't be using interpreted code (or byte-code interpreted code, for that matter), right? |
|
Re:From the article... (Score:5, Insightful) by Daniel Phillips (238627) on Sunday February 09, @12:25PM (#5264627) (http://nl.linux.org/~phillips) |
| I am, however, a little leary on the performance parity bit.
Don't get me wrong, I love programming in Python, but I know from
experience that it still costs a good bit to create all the dictionaries
that are used for frame construction, global maniuplation, and object
management. I did a little benchmarking recently, and I can confirm that for typical algorithmic benchmarks (not heavily library or IO oriented) Python is more than 100 times slower than C/C++. There's a Python "specializing compiler" called Psyco that produces significant speedup, running my little fibonacci test around half the speed of C, very impressive. Java on the other hand has had huge amounts of effort and money put into making it run faster, and to my surprise, I found it now runs my fibonacci benchmark faster than gcc-compiled C. Overall, Java performance has improved from horrible to tolerable. Programs are still taking a long time to start, even on a beefy machine, but to be fair, I've seen some long startup times on some C++ programs as well. Python really beats Java in startup time, with the result that Python gets used here and Java doesn't. Python is, however, fast enough for a great many applications. I'm just a little skeptical about it being quite as fast in certain aspects. I see Pysco has made it into Debian Sid, this is a good sign. |
|
Re:From the article... (Score:1) by Internet Dog (86949) on Monday February 10, @01:22PM (#5272079) |
I did a little benchmarking recently, and I can confirm that for typical algorithmic benchmarks (not heavily library or IO oriented) Python is more than 100 times slower than C/C++. There's a Python "specializing compiler" called Psyco that produces significant speedup, running my little fibonacci test around half the speed of C, very impressive. If you are testing something like fibonacci encode in pure Python then yes it will be 100 times slower than C/C++. But if you are doing real world work then you can use the Python library for the most commonly used algorithms, and the libraries are generally well optimized. It's the Batteries Included part of Python that makes it such a productive environment. Optimization is suppose to be the last step in the coding cycle. Get it write in Python first and then recode the bits that are too slow to tolerate in C. People are using Python for high performance applications. It's all about good software design. If performance was an issue then LLNL wouldn't be using Python to control applications that run for days on supercomputers. Performance isn't an issue because the Python code just sets up the problems to be solved. Python assembles the standard algorithsm and calls them with the appropriate datasets. Also, the Zope server, written in Python, scales to very large web sites because it uses well placed optimization |
by Bruce A. Tate, Justin Gehtland
$23.07
based on 20 reviews.
Product Description:
Sometimes the simplest answer is the best. Many Enterprise Java developers, accustomed to dealing with Java's spiraling complexity, have fallen into the habit of choosing overly complicated solutions to problems when simpler options are available. Building server applications with "heavyweight" Java-based architectures, such as WebLogic, JBoss, and WebSphere, can be costly and cumbersome. When you've reached the point where you spend more time writing code to support your chosen framework than to solve your actual problems, it's time to think in terms of simplicity. In Better, Faster, Lighter Java, authors Bruce Tate and Justin Gehtland argue that the old heavyweight architectures are unwieldy, complicated, and contribute to slow and buggy application code. As an alternative means for building better applications, the authors present two "lightweight" open source architectures: Hibernate--a persistence framework that does its job with a minimal API and gets out of the way, and Spring--a container that's not invasive, heavy or complicated. Hibernate and Spring are designed to be fairly simple to learn and use, and place reasonable demands on system resources. Better, Faster, Lighter Java shows you how they can help you create enterprise applications that are easier to maintain, write, and debug, and are ultimately much faster. Written for intermediate to advanced Java developers, Better, Faster, Lighter Java, offers fresh ideas--often unorthodox--to help you rethink the way you work, and techniques and principles you'll use to build simpler applications. You'll learn to spend more time on what's important. When you're finished with this book, you'll find that your Java is better, faster, and lighter than ever before.Sam Wilson (Philadelphia, PA USA) - See all my reviews
This book delivers a great message in the worst possible way.
It is useful if you are trying to persuade a PHB (management) that going with a full-blown EJB solution doesn't make sense.
If you need to convince an architect about this, give them Rod Johnson's book "Expert one-on-one J2EE Design and Development without EJB".
If you want to actually learn anything about the approach and philosophy, don't use this book. For one thing, the authors are working on a broken definition of "coupling" and fail to address "cohesion" by its proper name. In short, there is a lack of depth and rigor in what they are presenting that, at times, leads them to recommend approaches that aren't necessarily valid. For example: Using a message passing API without a strict message format definition (such as a WSDL definition in the WS world) actually leads to tighter coupling because the author of a service client must inspect the code of the service in order to understand the rules of exchange (the API). By definition that is tight coupling. The omission is minor, but significant in understanding the pitfalls of message-oriented service integration.
In short, AOP and related ideas are all about cohesion. Not just on the function or method level, but on the interface and class level. "Separation of concerns" sounds a lot like "functional cohesion". Not addressing this well understood issue by its formal name denies the reader the opportunity to find the broader body of knowledge on the subject. Why reinvent the wheel?
I guess if I had to sum up why this book isn't worth your money is because it is dogmatic and not prescriptive. The great thing about Rod Johnson's book is that it tells you not only when it is appropriate to take this approach, but the different ways to do so. The examples presented here are straw-men and "hello world" (as described above). What would be nice is a full example that brings all the pieces together. An implementation of the Java Pet Store using this approach, fully described point-by-point would be a nice approach.
Simple, and elegant, June 14, 2004
Reviewer: A reader
If I were looking for a Spring or Hibernate book, this one would let me down. But that's not what Gehtland and Tate are trying to do. They are showing why Spring and Hibernate are important, and how they have passed up enterprise java beans. They have shown basic rules for lightweight development, and they have done it effectively. The book is simple, well-written, and in conflict with established J2EE development. I get into the emphasis on JUnit.I also like how Gehtland and Tate show me more than programming. They let me see how companies sell. They show me how a better process can work. I like extreme programming, but my manager doesn't. They give me some good ideas about how to use the best parts without doing all of XP.
I also like the idea of showing the principles, and then seeing how those principles apply to open source software, and then showing me how to put them into use. I don't think that the book would have been useful if they would have simply tried to invent some application that fit their model. Instead, they picked a couple of open source projects that seem to do what they are advocating.
Lighter Faster java is a home run. If you're looking for a Spring book, just go buy Expert J2EE One on One. If you want to understand why Spring, and other technologies like it, are important, get Lighter Faster Java. I can understand how to program Spring and Hibernate with tutorials on line. This book gives me something far more valuable. Insight.
I think I'm also going to pick up one for my boss.
Reviewer: Dwight Gunning (Toronto, Ontario) - See all my reviews Better, Faster, Lighter starts by explaining the basic problem in J2EE, complexity and API bloat, and then builds around five principles that should guide Java application development. Each of these principles are enclosed in an individual chapter, and in the second half of the book, these principles are explained using open source frameworks and example code.
The most useful chapter for me was the chapter called "You Are What You Eat" as it explains alternatives to the standard J2EE architecture. It discusses all the major technologies that J2EE architects and developers care about - XML, Web Services, Session and Entity EJBs, Distribution etc, and gives scenarios under which it is suitable or unsuitable to choose each. This is the sort of information that is useful for persons who make architectural or design choices. The book also proposes two alternate deployments to the traditional 3-tiered architecture and gives reasons why these would lead to improved performance and lower complexity. This chapter explains how to make the technical decisions that will impact application development down the road.
This book gives an introduction to two of the most popular open source frameworks today - Spring and Hibernate, and argues that they have become successful as they focus on simplifying Java development. The chapters on Hibernate and Spring are relatively short at 22 and 25 pages respectively, and so should not be relied upon for a detailed exposition into these frameworks. Persons wanting to get up to speed with these technologies should buy Rod Johnson's Expert One on One J2EE Development without EJB, or Matt Raible's Spring Live, as well as the Hibernate in Action when these books are released. But the chapters fit nicely into the overall argument in favor of simple tools that help simplify development.
The Spring chapter explores the JPetstore sample application that uses IBatis as the persistence layer. Later on Bruce Tate discussed moving to Hibernate, and also supports the use of JDO.
Better, Faster, Lighter Java is a little different from the traditional Java/J2EE books, and is written in a conversational, rather than a technical style. Thus it's more useful for persons seeking the big picture surrounding Java development, rather for pure techies. Relatively few books focus on the why of application development, and I recommend this book as one of these. If you enjoy reading authors such as Rod Johnson, Martin Fowler, and Scott Ambler, then this book won't disappoint.
ITWALES.COM - An introduction to scripting languages
[PDF]
A comparison of object oriented scripting languages: Python and
Ruby
File Format: PDF/Adobe Acrobat -
View as HTML
"Just because the Java API, or any other API written for Java has documentation, doesn't mean that it's always obvious how to interact with it properly. " Part one of a two-part article
See: Two Java Scripting Languages Close-upWhen faced with a new engineering project or task, one of the first questions to cross a developer's mind is often "What language am I going to write this in?" Sometimes Java seems like overkill; we'd like to throw together something quick and dirty, and it might be nice to do interactive development. Typically in such situations, developers prefer Perl, Python, or even Tcl. However, there is a large array of new, neat scripting languages built to take advantage of the Java virtual machine that might be able to better serve your needs than one of those old workhorses. In this article, we're going to look at a few of the more interesting Java scripting languages currently available.
What advantages are there to a language targeting the Java virtual machine? There are many advantages to the person designing the language. Most immediate is portability; the new language has instant access to all platforms for which there is a Java virtual machine. One of the biggest pluses that you'll see in many of these languages is the ability to interoperate easily with Java. If you're used to the depth and breadth of features provided by Java APIs, this benefit may be worth pursuing.
Of course, most of these languages are somewhat off the beaten path, which is a place some developers don't want to go, and rightly so. Braving a language with a small user community that might disappear at any time is not for the faint at heart, no matter how cool the language is. For example, a very cool Java-based scripting language formerly called WebL is currently embroiled in legal battles causing it to disappear from its Web site. Not all Java-based languages are such big risks, though. For example, JPython enjoys a reasonably sized user base and has strong support from the Python community. People get paid full-time to work on it, and that probably won't change.
How about JavaScript? It turns out that JavaScript has nothing at all to do with Java. JavaScript was originally a language by Netscape called LiveScript. When Java first came out, Netscape made a deal with Sun to change the name to JavaScript. The whole goal was to take advantage of the Java hype. Other than the name, JavaScript has nothing to do with Java, beyond the fact that they both can work in a Web browser. JavaScript doesn't use the Java Virtual Machine, or anything.
(Ironically, Sun originally planned to deploy John Ousterhout's Tcl as the first scripting language for Java.)
Slashdot Why is Java Considered Un-Cool
jg21 writes "After the Slashdot discussion on Paul Graham's 'Great Hackers' essay, it had to happen. Java developers have taken umbrage at Graham's assertion that "Of all the great programmers I can think of, I know of only one who would voluntarily program in Java. And of all the great programmers I can think of who don't work for Sun, on Java, I know of zero." Now in JDJ Sachin Hejip pinpoints the Top Reasons Why Java is Considered Un-Cool and to tries to debunk them. He levels some of the blame at the Java compiler for "too much chaperoning" and speculates that Java fails the geek test precisely because "it's such a language-for-the-masses." But isn't he missing the point? Enterprise-grade apps and "coolness" may be inapproriate bedfellows. Besides, does any language offer both?"
|
What is this responding to.. exactly? (Score:4, Interesting)
by Defiler (1693) * on Tuesday August 24, @09:32AM (#10055164) |
| I'm not sure the article author has actually read the Paul Graham
essay that he is responding to. He almost entirely fails to discuss any of the attributes that Graham assigns to languages that 'Great Hackers' like to use. In particular, Graham claims that terser languages are more powerful [paulgraham.com], because studies have shown that coders churn out a pretty constant number of lines per day, regardless of the programming language. Java is anything but terse. I could go on, particularly since the Sun JVM isn't open source, and Graham makes a point of claiming that Great Hackers prefer to use open source tools. I think frantic defensive articles regarding Java aren't helping anyone. The managers that choose Java don't read Paul Graham articles, and I doubt Paul Graham much cares what a Java-oriented business journal has to say about his articles. Please note that I am just relating the opinions that Graham has put on his website. I do not necessarily share his views. |
|
Re:Words from a programmer rather than a end user (Score:4,
Insightful) by BigGerman (541312) on Tuesday August 24, @11:51AM (#10057018) |
| God bless you all. I am glad that these are the only things the guy who truly hates Java can come up with Eveything you listed is your friend, not enemy. Once you program for a while (and I mean 5,6,10 years), it will start coming to you. Often, downright ugly, this "feature" ensures that every object is what you think it is. You delegate all the checking to the compiler so you program, when it is incorrect, fails early, in fact, fails before it runs. Failing early is the sign of great code. Exception handling is a marvelous feature once you realize that from every situation there may be more than one (or two, Well, they are two completely different things, representing completely different animals in the real world. Why would you expect to be able to compare,assign, etc. apples to oranges? Tend to agree with you there. Because IT IS an error when precesion is lost? bytes are bytes and numbers are numbers. etc., got to go, do some uncool programming. |
|
Re:Are your apps constantly restarting? (Score:5, Insightful)
by dasmegabyte (267018) on Tuesday August 24, @12:18PM (#10057419) (http://www.dasmegabyte.org/ | Last Journal: Wednesday June 23, @12:41AM) |
| I've mentioned this before, but the primary difference between a
C/UNIX programmer and a C#/Java/Windows programmer is the perception of
what constitutes a program. In UNIX, a program is usually a tiny little thing which passes its output to other tiny little things, creating a network of programs controlled by a lightweight master program. Because of this, programs HAVE to have a small footprint and have to start up and close down quickly. A good UNIX program does only what it's supposed to, and then it quits. In a Java/C#/Windows program, you generally start the program once per day/week/year. The program, once started, calls objects with functions that operate the same as individual programs in the UNIX paradigm. Because the program is doing all of the work and all of the flow control, it doesn't matter if the thing starts or stops quickly, doesn't matter if it uses a lot of memory, because you're not going to be using that memory for a whole lot else. A good Java program does so much, it's almost like its own windowing or operating system. The essence of "I don't understand OOP, it's full of bloat" is the perception of what a program is and does. If you think a program should do one small thing and then pass its output or control to another program, you're essentially in the OOP mentality already...substituting processes for objects and programs for functions. On the other hand, if you believe as I do that programs should sit open and ready to use on a whim, even the fast startup time of the average UNIX utility is too much. You need the memory allocated, the commands loaded and ready to handle whatever you've got to do -- which is why OOP makes sense. You don't start your notebook every time you need to jot a note (I don't anyway)...you just pick it up and write. Anyway, to get on topic: I always thought Java *WAS* cool. All the under-40 programmers I know LOVE Java, even if they don't use it. It's almost a spiritual thing (I plainly remember wearing a "Java is the Way" back when I was a Java coder) and it's even more mysterious because the older generation of C coders didn't like it. Not disposing of objects and relying on GC is the programmatic equivalent of not cleaning your room. And a good UML diagram reads like a map of a futuristic city. |
|
Re:Are your apps constantly restarting? (Score:5, Interesting)
by kill -9 $$ (131324) on Tuesday August 24, @12:55PM (#10057917) |
| I (like many others) have been saying for years that its a matter of
right tool for the right job. Also, I'm very competent in Java, C/C++
and Perl. I also, typically develop exclusively for UNIX and stick to
the UNIX philosophy of building small, highly configurable/reusable
programs wherever I can.
The truth is though, not all applications can be distilled down into simple pipe/filter utility-type solutions. In these cases I typically like objects. If you understand OO programming, and I have found few who can both claim they understand and actually do (its about a 1:5 ratio from my experience) you can build very complex/robust systems very quickly. The tradeoff, memory. In this case I usually use java. Yes, its restrictive, and you can't do everything you can in a different language like Smalltalk or C++, but for most things it is capable. Its also cross-platform, if you know what you're doing, and there are hundreds of "standardized" API's for doing lots of stuff. Not to mention, because of those API's, you can actually get cross-platform database connectivity, web applications, and in theory but not really yet, enterprise services. If it comes to writing simple utilities, throw away code, anything that I feel falls into less than 100-200 lines of Perl code, I'll use Perl typically. My experience with Perl is that it doesn't scale, from a software management perspective, as nicely to large complex systems. Its usefulness though, is that you can do some pretty powerful stuff, without having to get bogged down in datatypes, complex exception handling, complex string manipulation and other language-isms that you have to deal with when you use a more strict language like C, C++, or Java. I also like the fact that anything I can write in C I can typically write just as easy in Perl, so for some of that systems programming type stuff that Java doesn't do so well, its nice to use Perl and not have to get into the guts of a C program As for C/C++, I avoid them whenever I can Again though, it comes down to right tool for the job. I've had this argument time and time again with PHP, Perl, and Python programmers and it always seems to come down to size/scope of the problems they are trying to solve. Most people who love these tools have written what I view as smaller applications. They have never had to write an e-commerce system that ties together multiple enterprise datasources, call into SOAP/CORBA etc services on another box, etc. Or the other thing I experience is that if they have, they end up reinventing some API/technology/feature that was already present in Java or that had they implemented their solution in Java would have made their life much easier. Anyway, this has been my experience, and this is the toolset I use to solve the problems that arise in my world. Everybody is different, use the right tool. |
|
Re:Maybe because it's slow ? (Score:5, Insightful) by StillNeedMoreCoffee (123989) on Tuesday August 24, @11:12AM (#10056423) |
| Well Java as I understand moves much of the optimization process down
into the JVM whereas a compiled language like C++ does that optimization
during compile time. Comparing the time I have spent waiting for C++
during the code, compile, run, code, compile run, I find I have wasted
much more of my time. With the Caching of classes and dynamic inlining
of code the JVM tunes up as you you go along. You are correct that this model has a start up delay which can be seen as a problem if you do a lot of startups, but like many applicatons say a web server that starts a JVM and keeps it running while the server is up it is a one time charge. I find that given the saftey of the language especially around automatic garbage collection compared with C++ my envirionment is rock stable and the online Web apps we have only come down with the hardware needs maintenance. The folks compainign about MS Java have a good complaint as that was an old buggy version of Java that has not been in general use for years by people using Java from the Sun source. The new versions of Java 1.4 I write my code on NT and W2k platforms (java 1.4.2) and field the same code on WNT W2k Sun Solaris with out modification and no changes for envirionments. With C++ or C# and the java clone this is impossible at this time. I have in the past had to field C++ code on different platforms and that was not a very nice time. How do you want to spend your time. Collecting your own Garbage, writting very very carefully so you can use your code in different environments, or do you want to just get the job done right and once and get on with it? |
|
Re:Maybe because it's slow ? (Score:5, Informative) by CurMo (172974) on Tuesday August 24, @09:57AM (#10055455) |
| Java really isn't -that- slow. That's a common misconception. Everyone thinks "Java is slow" because the only time they experience Java is in a Swing app. Swing is VERY bloated and therefore very slow. The only other "slow" processes in Java are Garbage Collection, which is pretty minimal if the app is written correctly, and the initial startup of the VM. Look, for example, at Eclipse IDE. Eclipse is a Java app, and its extremely powerful and not very slow. Why? They use their own widgets that have less overhead, they are not using Swing widgets. Also, a correctly written OpenGL java app has been proven to perform at 85% the speed of its C counterpart (yes C, not C++). A couple of guys (I can't find the link) ported QuakeII to java to get this statistic. Not bad considering the relative youth of OpenGL bindings in Java. I once had a "Java Sucks" attitude myself (I've been a hardcore C++ programmer for over 9 years), but I must say, after using the language for quite some time (~2 years), I've become very fond of it, and have written several large & FAST Java apps -- in about 70% of the time it would have taken to write in C++. |
|
Depends ... (Score:5, Interesting) by gstoddart (321705) on Tuesday August 24, @10:48AM (#10056122) (http://slashdot.org/) |
|
|
Re:Depends ... (Score:5, Informative) by Saucepan (12098) on Tuesday August 24, @11:24AM (#10056617) |
C++ has been around so long that by now there are jillions (possibly even hojillions) of C++ libraries/frameworks/APIs. Since you say you don't need a GUI kit, and assuming you are doing server programming, you might find ACE [wustl.edu] helpful. I used ACE for a previous multithreaded server and the project was very successful. We developed on Linux and FreeBSD but had no difficulty porting to Solaris, and could have ported to Windows with a couple of days of effort (we had use the occasional POSIX-specific idiom, but this was our own fault, not the toolkit). The author, Douglas Schmidt, is a well-known standards wonk and performance freak -- an interesting combination that results in a kit that provides full cross-platform support while running hard with C++'s approach of "you don't pay for it if you don't use it." The kit included a full CORBA ORB [wustl.edu] that supported realtime operation (ie, bounded maximum delay). Probably the best compliment I ever heard about ACE was a from a very senior coworker who commented that ACE was "not bad, for C++." Trust me -- from him, that was high, high praise. Having said all that, when I have to share the tree with other developers, Java is my favorite mainstream language. |
|
Re:What is this responding to.. exactly? (Score:5, Insightful)
by jimfrost (58153) * <[email protected]> on Tuesday August 24, @11:14AM (#10056453) (http://www.frostbytes.com/~jimf) |
| studies have shown that coders churn out a pretty constant
number of lines per day, regardless of the programming language
This is true, but that is not the whole picture. One of the things that was obvious right away is that minimizing the number of things the programmer can do wrong causes a significant jump in the effective productivity of the programmer. Brooks talks about this in the Mythical Man Month as it related to assembly versus high level languages, but we do see the same effect when moving between a language like C and something like Smalltalk or Java. It has been my experience that a good programmer writes more and higher quality code in Java versus C or C++, largely due to three factors: 1. Mandatory exception handling forces error handling down into the code where it can best be dealt with. In other words, you have to work harder to not handle abnormal situations. 2. Garbage collection eliminates whole classes of memory mismanagement problems. 3. Standard libraries contain many useful classes that had to be written independently in C/C++ (leading to a variety of different container classes, for instance, of widely varying usability and quality). All three of these affect both time to deliver and quality of delivered
code. We're not talking about minimal changes in productivity, either.
I've been watching and working with Java and C++ since In any case I guess I would have to vehemently disagree with Graham's contention that great hackers don't use Java. I suspect that is more a matter of which circles you run in, as that certainly doesn't hold true in my experience. There are fewer using it today than three or four years ago, but I surmise that that is mostly a matter of language maturity; the best programmers tend to sit on the bleeding edge, and that's not Java anymore. Your mileage may vary, contents may have settled during shipping, etc. |
|
Re:What is this responding to.. exactly? (Score:4, Interesting)
by TheWanderingHermit (513872) on Tuesday August 24, @12:09PM (#10057294) |
| Java is anything but terse. I know there's been a gazillion comments, but there's one thing I don't see mentioned that I want to mention. Before I do, a brief note on my background: I learned BASIC in high school in the '70s, then Fortran and Vax 11/780 Assembler in college, then taught myself 6502 Assembler and programmed a lot on my Apple I started with (and hated) Tcl. I found a book on Perl that was about 75% off, bought it, and was writing useful Perl code in under a day. When I had to learn Java, it took several books and was 2-3 weeks before I could write anything useful (in part due to needing to get used to the API before I could do anything I needed). When I code in Java, I'm always reminded of the scene in Spaceballs where Col. Sanders keeps saying, "Prepare for..." and Dark Helmet interrupts and says, "Why do you have to prepare for everything?" In Perl, if I want to do something, I do it. It takes a line or two of code, and I'm done. In Java, to do something I have to prepare for it AND do it. I often have to create from 1 to 3 objects to finally get the object I need, then I can finally do what I wanted to do. For example (and please don't get picky -- I'm picking a simple, quick example and there are thousands of others), if I want a list of files in a directory, in Perl it's: @file = glob($filename."/*"); In Java, I have to do: File myFile = new File($filename); String[] myList = myFile.list(); It's a small example, and I know I can combine creating the myFile object with getting the file list, but the point is I can't just DO it, I have to prep it and do it. I'm always going around my thumb to get to my elbow. In Java, I'm too busy keeping track of object types, creating objects (and sometimes creating objects, using that object to obtain another, then using the obtained ojbect in creating a third...) that I feel like a lot of my focus is on taking care of Java's needs rather than on writing my own program. I like working in Java. I like the cross platform abilities. I like Swing, since it is (to me) an esay GUI to write for. I like the class structure. But I don't like writing in Java as much as Perl and, given a choice, I'll take Perl whenever possible. I've found I can put a program together in Perl in a day and it'll take 2-3 to write the same thing in Java. |
|
COBOL (Score:5, Insightful) by sql*kitten (1359) * on Tuesday August 24, @09:35AM (#10055191) (http://www.kitten.org.uk/ | Last Journal: Tuesday August 24, @08:45AM) |
| Java is the new COBOL. No, I mean that quite seriously. COBOL means "COmmon Business Oriented Language". Java is the language of choice for modern day corporate application development. In the corporate world - which probably accounts for more actual lines of code than anything else - applications fall into two categories, forms (inputting data into databases) and reports (getting data out of databases). The corporate world wants legions of cheap, interchangeable programmers to work on these applications. Kids are taught Java at college or learn it themselves. The language makes it very easy for one person to work on another person's code, and it makes it quite painless to document your work as you go. That's the reason "hackers" don't like Java - they've just transferred their traditional dislike of COBOL to it. |
|
Too verbose (Score:4, Insightful) by random_culchie (759439) on Tuesday August 24, @09:35AM (#10055196) |
| Some of the things in java are terribly verbose. especially when going
to design GUIs. Using the language you just "feel" as if there should be an easier way. I'm no fan of microsofts products but I think C# is an excellent language to program in. It addresses alot of Java's shortcomings and it is a joy to program in. |
Core of IT The Virtual Machine History
One problem that has plagued programmers for many years is the idea of creating truly portable computer programs. In other words, programmers want to write one program that will work on any platform. In the mid 1990’s this idea has nearly been made possible utilizing the idea of the virtual machines to create the Java programming language.
The idea of the Java programming language, however, was not a new idea in the 1990’s. It was actually thought of in the late 1970's by a gentleman named Bill Joy. Joy thought about creating a language that would merge the best features of MESA and C. Other projects (like co-founding Sun), however, intervened and it would be many years before this idea became a reality. By the early 90's Joy was getting tired of huge programs. In late 1990 Joy wrote a paper called Further which outlined his pitch to Sun engineers that they should produce an object environment based on C++. Around this time James Gosling had been working for several months on an SGML editor called "Imagination" using C++. Due to Gosling’s frustration with C++ on this "Imagination" project, the Oak programming language was created.
Patrick Naughton started the Green Project on December 5th, 1990. Naughton defined the project as an effort to "do fewer things better". That December he recruited Gosling and Mike Sheridan to help start the project. Joy showed them his Further paper, and work began on graphics and user interface issues for several months in C.
In April of 1991 the Green Project (Naughton, Gosling and Sheridan) settled on smart consumer electronics as the delivery platform, and Gosling started working heavily on the Oak programming language. Gosling wrote the original compiler in C; and Naughton, Gosling and Sheridan wrote the runtime-interpreter, also in C. Oak was running its first programs in August of 1991.
By the fall of 1992 "*7", a cross between a PDA and a remote control, was ready This was demoed to Scott McNealy, Sun's president, in October. Following that the Green Project was set up as First Person Inc., a wholly owned Sun subsidiary. In early 1993 the Green team heard about a Time-Warner request for proposal for a settop box operating system. First Person quickly shifted focus from smart consumer electronics to the set-top box OS market, and placed a bid with Time-Warner. Fortuitously, Sun lost the bid. First Person continued work on settop boxes until early 1994, when it concluded that like smart consumer electronics settop boxes were more hype than reality.
Without a market to be seen First Person was rolled back into Sun in 1994. However around this time it was realized that the requirements for smart consumer electronics and settop box software (small, platform independent secure reliable code) were the same requirements for the nascent web. For a third time the project was redirected, this time at the web. A prototype browser called WebRunner was written by Patrick Naughton. After additional work by Naughton and Jonathan Payne this browser became HotJava. In 1995 Oak was renamed Java. In May of 1995 the first Java Development Kit (JDK) 1.0 alpha was released. Since that time there have been several revisions leading up to the current version of the JDK 1.2.
[PPT] Java: It's better than you think, for reasons you haven't realized ... -- great presentation !!! As if directly addressed to me ;-)
| File Format: Microsoft Powerpoint 97 - View as HTML |
[Feb 29, 2004] A_wolf's_in_sheep's_clothing By David Berlind
In case you missed the most recent chapter in one of the most important power plays taking place in the computer industry, last week IBM sent an open letter to Sun urging the company to turn Java over to the open source community. To Sun, the company that gave birth to Java, the letter must have seemed like a Trojan horse.
The letter was sent via e-mail by IBM's Rod Smith, vice president of emerging technology, to Sun's chief engineer Rob Gingell, and it earned the "open" classification because the press was copied on the note.
To the untrained eye, it appears as though Smith is asking Gingell to make Sun practice what it preaches. The note quotes a question posed by Sun chief technology evangelist Simon Phipps during the most recent gathering of Eclipse supporters: "Why hasn't IBM given its implementation of Java to the open-source community?" In the letter, Smith goes on to characterize the Phipps quote by saying, "Simon's comment appears to be an offer to jointly work toward this common goal." I'm rather sure that wasn't the gist of his comment. Although I wasn't present to hear the quote, I suspect that it was a rhetorical question posed by Phipps in an entirely different context than the one Smith suggests in his letter. So far, Sun has been unavailable for comment.
Let's forget for a minute that as important as Gingell is inside Sun (he is responsible for the overall technical architecture and direction of Sun's product line), such business decisions are not made by one person and certainly not by Gingell alone. By copying the press, the letter subtly suggests that hypocrisy worth investigating is afoot. It paints a picture of an IBM with its arms extended in hopes of spreading the Java love. If Sun doesn't play ball, it could be perceived as defiantly resisting the combined wills of the Java and open source communities.
But if there's one tiny clue to the letter's disingenuous nature, it's the inclusion of Gingell's e-mail address. Such a faux pas in "public" e-mail etiquette is commonplace for newbies to email, but not for someone like IBM's Smith. As a continuation of IBM's almost four-year-old pursuit to wrest control of Java away from Sun, it was a good chess move by IBM. No doubt Gingell's inbox is overwhelmed with inquiries.
With Gingell and Sun both mum (as IBM knew they would be), the press coverage may have unwittingly played right into IBM's hands. All sorts of anti-Sun verbiage is sprouting up. Some say that Sun, and not the other JCP members, is preventing Java from being truly open, or that IBM wants to invest in an independent, open-source Java implementation for the benefit of all. Rick Ross, a Java developer, said that Sun accounts for only about 5 percent of the Java industry, yet it has control of the platform positioning and is not promoting it enough.
Sun had little choice but to look like the bad guy. If you ask me, the real wolf here is IBM.
Since May of 2000, when IBM tried to organize a Java-licensee walkout just before Sun's annual Java lovefest (JavaOne) under the auspices of an organization called openserver.org, BigBlue has relentlessly been pursuing the freedom of Java.
For IBM, Java plays a starring role in its WebSphere product line, which aims to deliver real-time data anytime, anywhere and to ease the cost and complexity of integrating disparate systems. Many riches and spoils await the leading provider of the glue that brings together all of the moving parts. For IBM, Java is that glue.
For Microsoft, .Net is the glue. Thanks in part to all of the collaborative work that IBM and Microsoft have done in the area of Web services (much of it without the blessing of Sun), the same roads that connected the two types of glue also make substitution of one for the other possible. Knowing that Microsoft itself is licking its chops at the prospect of supplanting Big Blue's big iron with .Net-based systems, IBM can ill afford to let another company control its fate. The last time IBM put itself in that precarious position with Microsoft and OS/2, it nearly destroyed the company.
Since the demise of openserver.org (Oracle backed out at the last minute), IBM has used every weapon in its vast arsenal to pry Sun's fingers off of Java. The most visibly successful of these maneuvers so far has been the creation of the aptly named Eclipse project. From the tools used to build applications for WebSphere, IBM extracted and open sourced an integrated development environment (IDE) for Java that, much to Sun's chagrin, invited developers to violate of one of Java's chief tenants--universal portability from one vendor's certified, compatible Java runtime to the next. Many of the third-party tool makers that supported the incumbent IDE NetBeans at the time rushed to support the IBM-backed project as well. The move drove a stake about as close to the heart of the Java community as IBM could get without running afoul of its Java license.
In addition to Eclipse, Big Blue, along with BEA, took another swipe at Sun with J2EE extensions. IBM and BEA, which combined have a controlling share of the market for Java-based application servers (known as J2EE), waited until precisely the day after the most recent J2EE standard was published by the Java Community Process (the organization which oversees Java standardization) to announce joint support for three proprietary J2EE extensions. Later, after the extensions had been turned over to the JCP for eventual incorporation as Java standards, Jonathan Schwartz, Sun executive vice president for software, discounted the move as a desperate response to Sun's own offering a free J2EE-based application server.
To me, the message to Sun was crystal clear: If Sun isn't willing to share control of Java with IBM, then IBM will figure out ways to take matters into its own hands. Smith's letter is a subtle hint to Sun that there's still a way to resolve their differences peacefully by giving up Java.
IBM's desire to see Java open sourced has many people confused. After all, given the way Java licensees can contribute to the evolution of Java, the Java Community Process bears many resemblances to the way open source software is developed. Two complaints that IBM has had over the years is that it has to pay to play, and even after paying there are no guarantees. Sun has the controlling veto vote over the specifications (known as Java Specification Requests or JSRs) that matter most to IBM.
However, IBM is hardly in a position to complain about either. After all, in 2003 IBM passed BEA for the top spot in J2EE market share. With the largest intellectual property portfolio in the world (said to command some $3 billion per year in revenues), IBM is hardly one to talk about having to pay for the use of someone else's invention.
As far as the veto power is concerned, no JCP member has ever come forward with evidence of a Sun veto having taken place. That said, there have probably been hundreds if not thousands of new ideas for Java that have never seen the light of day simply because the person or company who thought of them knew Sun would never allow them.
If there are any clues to IBM's pain point, they can be found in a 2002 interview I conducted with Sun's Gingell. Commenting on the open sourcing of Java, Gingell said: "We've practically open sourced [Java] anyway. The only difference between JVM licensing and open source is that we say you have to stay compatible. An open source license says that you don't have to stay compatible. Compatibility is actually what the Java community cares about. So if you're going to use our stuff you have to stay compatible. Otherwise, there's no difference between it and an open source license….The reason open-source zealots don't like the Sun Community Source License is because it requires that you stay compatible. When they say, 'We'd just rather you delete that phrase,' we say no."
To understand why this conflict comes down to compatibility, and who the arbiter of it is, look at what has happened in the Linux community. As Gingell has said, and as the different distributions of Linux have proven, there are no compatibility requirements in the open source world. Despite the existence of a single Linux kernel, there are a sufficient number of incompatibilities between the different distributions of Linux to say that they are not only incompatible, but also difficult to substitute for one another.
In my LinuxWorld interviews of two IT executives from Midwestern banking giant, The Northern Trust, I learned that the company had gone so far down the Red Hat path in their Linux deployments that there was no going back, even if an alternative distributor like Novell (SuSE) offered a better safety net (Red Hat offers none) in the event that the bank was sued by SCO. The Northern Trust's situation exemplifies how, at least in the U.S., Linux compatibility isn't necessarily defined by the open source community, but rather by the vendor with the largest market share. This situation makes it difficult for other distributions to compete, and more importantly, for customers to have greater freedom of choice.
It's precisely for this reason--compatibility--that IBM is hoping to see Java open sourced, but Sun has so far refused to budge. As a Sun Community Source Licensee, IBM is obligated to not only make WebSphere compatible with other J2EE implementations, but to warn developers should they venture down the path of proprietary extensions that effectively eliminate any chances of portability without reprogramming.
If Sun relinquishes control as the arbiter of compatibility by open sourcing Java, it leaves the door open for IBM's WebSphere to become the Red Hat Linux of J2EE--the defacto standard J2EE by which all others are measured. Much the same way Red Hat's proprietary extensions to Linux keep the competition at bay, and customers from switching, WebSphere would be assured of market dominance no matter what secret sauce its competitors come up with. More importantly to IBM, it can respond immediately to any threats from the .Net world with little or no interference because of overidding compatibility concerns.
As long as there's an official standard that all licensees (including IBM) must conform to, no single vendor is assured of a lock on the J2EE market or can be put in the position of establishing a de facto standard including proprietary technologies that are not freely available to competing vendors (as is the case in the Linux market).
Despite IBM's current lead, it is precisely this "standard effect" that poses the biggest threat to Big Blue, particularly from free implementations of J2EE like JBOSS and Sun's own Application Server 8.0. With free versions of certifiably compliant J2EE-based application servers floating around in the market, IBM has a challenge on its hands that it might not otherwise have if WebSphere were the defacto standard.
You can look at JBOSS to understand the real context of the question that Simon Phipps originally asked at EclipseCon. As most Java watchers know, JBOSS is an open source implementation of J2EE. Although it may appear as subtle, there's actually a big difference between an open source implementation of a Java specification like J2EE, and turning over development of the specifications to which those implementations must conform to the open source community. If I read Phipps' question correctly, he was challenging IBM to release the source code behind WebSphere itself to the open source community - something that, based on the precedent set with JBOSS, IBM would be allowed to do.
As it turns out, Sun has been gradually paving the way for open source implementations of JSRs to exist since 2002. In August of 2002, Sun broke an open-source logjam with the Apache Software Foundation, and since then has been slowly bowing to the pressure of the open-source community. According to Gingell (in my earlier interviews), allowing open-source implementations of Java specifications is not as simple as throwing a switch and magically saying Java is now officially open source. Since most of the existing Java specifications contain contributions from other vendors that were made under an earlier intellectual property policy of the JCP that had no allowances for open source licensing, it's not within Sun's rights to turn around and open source all the Java specifications any more than its within its right to turn around and open source Solaris (which depending on who you believe, now contains intellectual property that belongs to Novell, SCO, or no one). In the 2002 interview, Gingell spells this issue out when he said: "The process by which Java evolved came with a set of terms that effectively prohibited anybody from using an open-source license. But that's not our intention. The way the JCP is built is that the person who does the work has the right to decide how it is they're going to make it available. After all, they did the work. Whether that's open source or some variant of open source or not open source at all, they can do whatever as long as the terms are not rejected by the Java community. The change we made recently was to make one of those options open source." That change is what paved the way for existing specifications to be colored by open source language on their next revision and for new ones to be colored with it from the get go.
Evidence that Sun was making good on that promise surfaced in November, when shortly after version 1.4 of the J2EE JSR was ratified by the JCP, The Apache Software Foundation and JBOSS Group were given the go ahead to not only produce J2EE 1.4 compliant implementations of Geronimo and JBOSS (respectively) but to seek compatibility certification for them as well. Should IBM wish to open source WebSphere, there would be little Sun could do to prevent it now that the cat is out of the bag.
This of course is a long explanation to my final reason for suspecting why Smith's response to Phipps' EclipseCon comments appears to be a wolf in sheep's clothing. Thinking no one would pick up on the subtle difference between turning over the Java specification process to the open source community and allowing for open source implementations of those specifications, Smith used Phipps' very carefully worded quote in his open letter to purposefully confuse the two issues for the press who was copied. "Why hasn't IBM given its implementation of Java to the open-source community?" Whereas Smith attempted to expose a hypocritical Sun, he actually ended up exposing a hypocritical IBM.
Finally, the last bit of evidence casting doubt on the motives of IBM and Smith is his well-known relationship with Gingell. If the letter were really an olive branch, the correspondence would have started with a phone call, and the press might never have known.
We may see a lot of changes in the JCP over the coming years. But, I very much doubt that one of them will be a relaxing of Sun's commitment to compatibility and portability. That not only protects other Java licensees, it protects you.
[Feb 29, 2004] Java theory and practice Fixing the Java Memory Model, Part 1
The Java platform has integrated threading and multiprocessing into the language to a much greater degree than most previous programming languages. The language's support for platform-independent concurrency and multithreading was ambitious and pioneering, and, perhaps not surprisingly, the problem was a bit harder than the Java architects originally thought. Underlying much of the confusion surrounding synchronization and thread safety are the non-intuitive subtleties of the Java Memory Model (JMM), originally specified in Chapter 17 of the Java Language Specification, and re-specified by JSR 133.
For example, not all multiprocessor systems exhibit cache coherency; if one processor has an updated value of a variable in its cache, but one which has not yet been flushed to main memory, other processors may not see that update. In the absence of cache coherency, two different processors may see two different values for the same location in memory. This may sound scary, but it is by design -- it is a means of obtaining higher performance and scalability -- but it places a burden on developers and compilers to create code that accommodates these issues.
What is a memory model, and why do I need one?
A memory model describes the relationship between variables in a program (instance fields, static fields, and array elements) and the low-level details of storing them to and retrieving them from memory in a real computer system. Objects are ultimately stored in memory, but the compiler, runtime, processor, or cache may take some liberties with the timing of moving values to or from a variable's assigned memory location. For example, a compiler may choose to optimize a loop index variable by storing it in a register, or the cache may delay flushing a new value of a variable to main memory until a more opportune time. All of these optimizations are to aid in higher performance, and are generally transparent to the user, but on multiprocessor systems, these complexities may sometimes show through.The JMM allows the compiler and cache to take significant liberties with the order in which data is moved between a processor-specific cache (or register) and main memory, unless the programmer has explicitly asked for certain visibility guarantees using
synchronizedorvolatile. This means that in the absence of synchronization, memory operations can appear to happen in different orders from the perspective of different threads.By contrast, languages like C and C++ do not have explicit memory models -- C programs instead inherit the memory model of the processor executing the program (although the compiler for a given architecture probably does know something about the memory model of the underlying processor, and some of the responsibility for compliance falls to the compiler). This means that concurrent C programs may run correctly on one processor architecture, but not another. While the JMM may be confusing at first, there is a significant benefit to it -- a program that is correctly synchronized according to the JMM should run correctly on any Java-enabled platform.
Society
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
Quotes
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
Classic books:
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|
|
You can use PayPal to to buy a cup of coffee for authors of this site |
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.
Last modified: March 12, 2019
