IBM has begun to use libraries from the Apache Harmony project in some of its production-level Java software, it was revealed at JavaOne last week. The move comes after years of IBM quietly contributing code to the Apache Harmony project, and it marked the first time IBM had publicly discussed its use of the software.
##CONTINUE##
When Craig Hayman, vice president of WebSphere, took the stage at JavaOne, he was ostensibly talking about hosting Java application servers in the cloud and backing them up with what he called “extreme transaction processing” through creative caching. Then Hayman spoke about Apache Harmony.
“In our regular shipping offerings, like WebSphere CE and Lotus Notes, we're using many of the Harmony libraries inside our JVM, and inside our core code. We contribute a lot to the Harmony codebase,” said Hayman.
While Hayman and Ted Ellison, vice president of the Apache Software Foundation and an IBM senior technical staff member, demonstrated what they categorized as “not your father's runtime,” they were also quietly showing the world that there was, in fact, an open-source Java ready for production environments, and that it did not come from Sun Microsystems (in the form of the OpenJDK).
Since Harmony reached near-completion in 2007, Sun has refused to allow the Apache Foundation access to its Test Compatibility Kit, essentially relegating Apache Harmony to the status of “un-certified Java.”
When asked whether he felt that a lack of TCK access would harm Harmony's image, Hayman said, “I think that's somewhat in the hands of the customers and whether they care or not. If you were to take [Apache] Geronimo running on [Apache] Harmony, what do you care about: Harmony or Geronimo?”
If users only care about running Geronimo, he said, the certification levels of what's underneath don't really matter to the users, as long as they work.
Jeffrey Hammond, senior analyst for application development at Forrester Research, said that IBM's move to Harmony is similar to its move toward Eclipse.
“I would call it a risk mitigation move,” He said. He also said that a lack of certification from Sun shouldn't scare users away. “IBM has had its own JVM inside its products for years, and nobody has complained about that."
Hayman elaborated on IBM’s plans for Harmony. “First, we want to show people that we think it's ready for prime time. The second is we want to show off some of the tooling to get developers interested in using and contributing to Harmony.
"The community is at that tipping point where it's important for us to be more vocal about what we're doing. We're shining a light on the capabilities and how it can be used."
Miko Matsumura, vice president and chief strategist for Software AG, said at JavaOne: “The thing that's wonderful about how open Java is as an economic system is that it's a checks-and-balances system. IBM deserves to have some power, in the sense [that] you don't want Oracle to be the exclusive steward of Java. It's almost at the level of an Apache-style meritocracy."
-----------------------------
BY Alex Handy
Source：SDTimes
Copyright © 1999-2009 BZ Media LLC, all rights reserved.
Showing posts with label JAVA. Show all posts
Showing posts with label JAVA. Show all posts
A Peak into the JavaOne 2009 Classrooms
As an attendee of the 2009 JavaOne Conference, I was eager to drilldown into the latest and greatest Java technologies and technical session offerings.
##CONTINUE##
Accordingly, I thought I’d start off by attending a session dedicated to the Java Platform SDK Version 7 (TS-5363). Unfortunately, to my despair, when I approached the designated classroom, I found that this session had been canceled.
Although I was a slightly disappointed, I knew that there where many other sessions to choose from. With only a few seconds to spare, I meandered along and found myself in a session entitled "Script Bowl 2009: A Scripting Languages Shootout" (PAN-5348). As a traditional Java applications developer, this session would have been my least favorite topic to explore. However, to my surprise, I found this session to be an interesting and excellent overview of the most popular and powerful Scripting Languages.
Basically, as with any piece of software or hardware, choosing a suitable Scripting Language depends upon the technical and business requirements; moreover, in this session, five major Scripting Language gurus battled it out. First of all, Groovy was presented; and for those traditional Java developers (such as myself) Groovy may be well suited as it has a Java-like syntax yet it is also agile and dynamic. Additionally, Groovy provides features that are currently unavailable in Java such as closures and regular expressions.
Secondly, the JRuby guru took the stage and praised JRuby for its reflective, dynamic and interpreted object-oriented concepts as well as all the interoperability with Java platform applications and existing Java user applications.
Third, there was a Jython demonstration, and for those Python programmers who are dedicated to the Python syntax but would like to utilize the plethora of Java Classes instead of Python modules, Jython could possibly be the antidote.
Fourth, the Scala representative showed off its code magic, and for those who prefer concise code, Scala provides the benefit of a short syntax and static typing which results in a boost in productivity. Scala is likewise seamlessly integrated with the Java libraries and existing Java application code.
Finally, Clojure (the newer kid on the block) was revealed. As it turns out, Clojure can very beneficial to concurrent programming in which deadlocks must be avoided. Actually, having worked on Artificial Intelligent systems that utilized both Lisp and Java, I found Clojure, given it’s similarities to Lisp, to be the most interesting of the Scripting Language that were discussed here.
After having my Bowl of Scripting Languages, I proceeded to find a session that was better suited for my interest so I selected a session entitled “Small Changes in JDK Release 7” (TS-4060). As the title suggests, changes and enhancements to the JDK are most likely to be release candidates if they are relatively small. This small partiality combined with a broad applicability predilection exists to ensure source compatibility, binary compatibility, and behavior compatibility. Currently, there are still 120 possibly proposed good language enhancements waiting to be born (or aborted).
So what language changes are we likely to see in SDK 7 and beyond? I’ll highlight a few that were of particular interest to me:
1.) Automatic Resource Termination – this change would eliminate the requirement of the developer to clean up his or her used resources. In particular, resource closing with those messy try-finally blocks or try-try-finally-finally blocks could be completely avoided. Great news, right?!
2.) The Diamond Operator < > – this enhancement would eliminate the need to retype the Generics on both sides of the assignment statement. Instead of repeating the full Generics syntax on the RHS of the statement, the developer would simple type < > on the RHS and the datatype would be implied from the LHS.
3.) Improved Exception Handling – this change allows developers to catch multiple exceptions in a single try-catch. For example, the following single statement would catch all three types of exceptions:
try { …
}
catch (NamingException, RemoteException, CreateException exc) {
…
}
Again, I view this one as a fantastic change - using a separate
try-catch for every possible exception gets rather cumbersome and
tedious.
4.) String Switch Statement - this change allows developers to define a switch statement based on the String type. For example, the following code would now be legal:
String input = “string”;
switch (input){
case "string":
System.out.println("I am a string!");
…
I personally feel that the String Switch enhancement was long overdue and I can’t wait to start employing it!
Well, now that’s a lot to look forward to! Additionally information on SDK Release 7 can be found on Joseph Darcy’s Project Coin website.
-----------------------------
BY Terry-Lynn
Source：ZDNet
Copyright © 2009 CBS Interactive Limited. All rights reserved.
##CONTINUE##
Accordingly, I thought I’d start off by attending a session dedicated to the Java Platform SDK Version 7 (TS-5363). Unfortunately, to my despair, when I approached the designated classroom, I found that this session had been canceled.
Although I was a slightly disappointed, I knew that there where many other sessions to choose from. With only a few seconds to spare, I meandered along and found myself in a session entitled "Script Bowl 2009: A Scripting Languages Shootout" (PAN-5348). As a traditional Java applications developer, this session would have been my least favorite topic to explore. However, to my surprise, I found this session to be an interesting and excellent overview of the most popular and powerful Scripting Languages.
Basically, as with any piece of software or hardware, choosing a suitable Scripting Language depends upon the technical and business requirements; moreover, in this session, five major Scripting Language gurus battled it out. First of all, Groovy was presented; and for those traditional Java developers (such as myself) Groovy may be well suited as it has a Java-like syntax yet it is also agile and dynamic. Additionally, Groovy provides features that are currently unavailable in Java such as closures and regular expressions.
Secondly, the JRuby guru took the stage and praised JRuby for its reflective, dynamic and interpreted object-oriented concepts as well as all the interoperability with Java platform applications and existing Java user applications.
Third, there was a Jython demonstration, and for those Python programmers who are dedicated to the Python syntax but would like to utilize the plethora of Java Classes instead of Python modules, Jython could possibly be the antidote.
Fourth, the Scala representative showed off its code magic, and for those who prefer concise code, Scala provides the benefit of a short syntax and static typing which results in a boost in productivity. Scala is likewise seamlessly integrated with the Java libraries and existing Java application code.
Finally, Clojure (the newer kid on the block) was revealed. As it turns out, Clojure can very beneficial to concurrent programming in which deadlocks must be avoided. Actually, having worked on Artificial Intelligent systems that utilized both Lisp and Java, I found Clojure, given it’s similarities to Lisp, to be the most interesting of the Scripting Language that were discussed here.
After having my Bowl of Scripting Languages, I proceeded to find a session that was better suited for my interest so I selected a session entitled “Small Changes in JDK Release 7” (TS-4060). As the title suggests, changes and enhancements to the JDK are most likely to be release candidates if they are relatively small. This small partiality combined with a broad applicability predilection exists to ensure source compatibility, binary compatibility, and behavior compatibility. Currently, there are still 120 possibly proposed good language enhancements waiting to be born (or aborted).
So what language changes are we likely to see in SDK 7 and beyond? I’ll highlight a few that were of particular interest to me:
1.) Automatic Resource Termination – this change would eliminate the requirement of the developer to clean up his or her used resources. In particular, resource closing with those messy try-finally blocks or try-try-finally-finally blocks could be completely avoided. Great news, right?!
2.) The Diamond Operator < > – this enhancement would eliminate the need to retype the Generics on both sides of the assignment statement. Instead of repeating the full Generics syntax on the RHS of the statement, the developer would simple type < > on the RHS and the datatype would be implied from the LHS.
3.) Improved Exception Handling – this change allows developers to catch multiple exceptions in a single try-catch. For example, the following single statement would catch all three types of exceptions:
try { …
}
catch (NamingException, RemoteException, CreateException exc) {
…
}
Again, I view this one as a fantastic change - using a separate
try-catch for every possible exception gets rather cumbersome and
tedious.
4.) String Switch Statement - this change allows developers to define a switch statement based on the String type. For example, the following code would now be legal:
String input = “string”;
switch (input){
case "string":
System.out.println("I am a string!");
…
I personally feel that the String Switch enhancement was long overdue and I can’t wait to start employing it!
Well, now that’s a lot to look forward to! Additionally information on SDK Release 7 can be found on Joseph Darcy’s Project Coin website.
-----------------------------
BY Terry-Lynn
Source：ZDNet
Copyright © 2009 CBS Interactive Limited. All rights reserved.
Sun rallies mobile faithful to simplified Java tests
Sun Microsystems and mobile partners are taking another stab at portability of Java applications as Apple, Google, and Research in Motion threaten to set de-facto standards.
##CONTINUE##
Together with France Telecom and Orange, Motorola, Nokia, Sony Ericsson and Vodafone, Sun announced the Java Application Terminal Alignment (JATA), which they promised would reduce the number of tests application developers would need to go through to ensure their applications run on different networks and handsets.
-----------------------------
BY Gavin Clarke in San Francisco
Source：The Register
© Copyright 1998–2009.
##CONTINUE##
Together with France Telecom and Orange, Motorola, Nokia, Sony Ericsson and Vodafone, Sun announced the Java Application Terminal Alignment (JATA), which they promised would reduce the number of tests application developers would need to go through to ensure their applications run on different networks and handsets.
Sony Ericsson claimed to have submitted up to 60 test cases and Orange 100 test cases to JATA.
Also promised are a publisher ID digital certificate to authenticate a person and application, and R&D signing for developers to test their applications.
Unified Test Initiative chair and director of technology for the Orange partner program Martin Wrigley cited the example of one Java programmer who had to make 14,000 builds of his application to target every single operator and language.
"We don't want customers getting something that doesn't work," Wrigley said. "The increase in software stores and volume in applications coming towards us is something we have to acknowledge and evolve testing to make it relevant."
As with another initiative to reduce the work building applications to different handsets - and reduce fragmentation in mobile market - two companies are conspicuous by their absence: Google and Apple. And this time they are joined by RIM.
In March Motorola announced Pulsar, a project to provide a common Eclipse-based tooling environment for different Java Mobile Edition (Java ME) SDKs. The goal is to extend Pulsar to native and HTML mobile applications. Backing Pulsar are Nokia and Genuitec, with IBM, RIM and Sony Ericsson Mobile.
Martin said JATA targets the addressable market of some 2.6bn Java ME devices, which - collected - is larger than the market owned by the iPhone and Google's Android, neither of which use Java ME. He said it was a mistake to see mobile as one market of handsets and service providers.
The unified standard effort is the latest big push to unify around Java ME and reduce fragmentation, which stops developers easily porting their applications to different devices and networks. Java ME has become a stable for many in mobile, but that hasn't stopped handset and service providers using only the bits they want to tune and juice their apps and lock developers in against the rival service providers.
Since the creation of Java ME, we've had CLDC and MIDP in an attempt to make sense of the chaos. And now, with Google and Apple exciting developers and service providers contemplating their own online stores for mobile, it's back to Java ME - only this time with unified testing.-----------------------------
BY Gavin Clarke in San Francisco
Source：The Register
© Copyright 1998–2009.
甲骨文CEO称将加大对Java投资力度
甲骨文CEO拉里·埃里森(Larry Ellison)周二在JavaOne大会上表示，收购Sun之后，甲骨文将继续加大对Java的投资。
##CONTINUE##
埃里森说：“合并Sun之后，甲骨文将继续增加对Java的投资，扩大社区规模，我们对此感到兴奋。”
埃里森还称，甲骨文的中间件战略将“100%基于Java”。他说：“对于我们而言，Java是一个极具吸引力的平台，因为它是一个开放、可扩展平台。我们整个下一代商业应用，即Fusion应用，将完全基于Java。”
埃里森说：“对于我们的客户，乃至整个社区，这一切都颇具吸引力。”同时，埃里森还对JavaFX大加赞赏，称JavaFX有望取代AJAX，因为许多开发人员并不喜欢AJAX。
另外，埃里森还提到了上网本，称甲骨文将来可能开发基于Java的上网本，向惠普和戴尔等PC厂商发起挑战。埃里森说：“我找不出任何理由来证明我们不能推出这些产品。”
-----------------------------
文章出处：新浪科技
作者：李明
##CONTINUE##
埃里森说：“合并Sun之后，甲骨文将继续增加对Java的投资，扩大社区规模，我们对此感到兴奋。”
埃里森还称，甲骨文的中间件战略将“100%基于Java”。他说：“对于我们而言，Java是一个极具吸引力的平台，因为它是一个开放、可扩展平台。我们整个下一代商业应用，即Fusion应用，将完全基于Java。”
埃里森说：“对于我们的客户，乃至整个社区，这一切都颇具吸引力。”同时，埃里森还对JavaFX大加赞赏，称JavaFX有望取代AJAX，因为许多开发人员并不喜欢AJAX。
另外，埃里森还提到了上网本，称甲骨文将来可能开发基于Java的上网本，向惠普和戴尔等PC厂商发起挑战。埃里森说：“我找不出任何理由来证明我们不能推出这些产品。”
-----------------------------
文章出处：新浪科技
作者：李明
Could next week's JavaOne be the last?
Oracle's plan to buy Sun could raise doubts about the future of the event
##CONTINUE##
Will next week's JavaOne conference be the end of the line for the annual Sun Microsystems-sponsored, week-long tribute to all things Java?
This year's conference will begin Tuesday, June 2, at the usual place -- the Moscone Center in San Francisco. Held since 1996, JavaOne attracts about 15,000 attendees per year.
But with Oracle set to buy Sun for $7.4 billion, will Oracle put an end to JavaOne and perhaps replace it with a Java emphasis at the massive Oracle OpenWorld conference? OpenWorld will be held in October at the same place as JavaOne.
BY Paul Krill
Source：InfoWorld
Paul Krill is an editor at large at InfoWorld.
©1994-2009 Infoworld, Inc.
##CONTINUE##
Will next week's JavaOne conference be the end of the line for the annual Sun Microsystems-sponsored, week-long tribute to all things Java?
This year's conference will begin Tuesday, June 2, at the usual place -- the Moscone Center in San Francisco. Held since 1996, JavaOne attracts about 15,000 attendees per year.
But with Oracle set to buy Sun for $7.4 billion, will Oracle put an end to JavaOne and perhaps replace it with a Java emphasis at the massive Oracle OpenWorld conference? OpenWorld will be held in October at the same place as JavaOne.
Asked what the future holds for JavaOne, representatives from Sun and Oracle declined to comment on Tuesday. A glance at the Moscone event calendar running from January to June 3, 2010, however, does not list JavaOne as a scheduled event. A Moscone representative did not know of future plans for the event. An austere Web page does exist for JavaOne 2010, stating the event runs June 21-24. The page invites submission of presentations.
Observers Tuesday offered varied perspectives, with Gartner analyst Roy Valdes speculating there might indeed be an end to JavaOne at some point. But for Oracle to suddenly pull the plug on JavaOne might give out the perception that the company does not care about Java. Over time, however, JavaOne could disappear, Valdes reasoned.
"Oracle may take a more hands-on approach to Java than Sun did," Valdes added. "However, this does not necessarily imply a single broad-scope conference on Java."
A prominent Java developer predicted a future for the conference.
"I'd be surprised if it's the last JavaOne," said Rod Johnson, creator of the Spring Framework for Java, who will give a presentation at next week's event on the 3.0 version of Spring. "I think in order for Oracle to succeed, they need Java as a language to continue to be successful."
"Assuming that they believe that JavaOne is a good thing for Java, and I think it is, I would expect [the event] to continue," Johnson said.
JavaOne will highlight Sun's JavaFX technology for rich media applications. Also featured will be a keynote by Microsoft Corporate Vice President Dan'l Lewin, who will talk about the company's software and services partnership with Sun that spans on-premise and cloud computing. Lewin's appearance will be the first time a Microsoft official has given a keynote speech at JavaOne. It might be the last, too, regardless of JavaOne's future, given that Oracle and Microsoft have not always gotten along.
Lewin also will cover interoperability between Java and Microsoft's .Net.
Meanwhile, fragmentation in the Java ME (Micro Edition) space will be the subject of a panel discussion featuring representatives from Sun, Sony Ericsson, and Orange.
Sun's Robert Brewin, vice president and CTO will discuss the pervasiveness of Java in a keynote talk. IBM, a longtime Java supporter, will discuss "extreme transaction processing" and "Smart SOA" at the show. James Gosling, Sun vice president and considered the father of Java, will detail Java-powered toys.
Topics covered in the many sessions at the event include:
- Java programming for real-time systems
- Script Bowl 2009, focusing on scripting languages that run on top of the Java Virtual Machine, including Groovy, JRuby, Jython, Scala, and a new entrant, clojure
- Eclipse Foundation technologies; Sun has long declined to join the open source Eclipse group, but Oracle is a member
- The Google App Engine cloud platform, which now supports Java
- Semantic Web programming
In conjunction with JavaOne, the CommunityOne West conference pertaining to open source software runs from June 1-3 also at the Moscone Center. Cloud computing will be a major emphasis at this event.
-----------------------------BY Paul Krill
Source：InfoWorld
Paul Krill is an editor at large at InfoWorld.
©1994-2009 Infoworld, Inc.
Sun seeks to build world's biggest App Store around Java
Sun will vet Java apps and check them for safety and content, and will charge for distribution
##CONTINUE##
Sun Microsystems plans to launch an App Store that could make Apple's look smaller than a 7-Eleven by comparison.
BY Dan Nystedt (IDG News Service)
Source：COMPUTERWORLD
Copyright 2009 IDG Communications. ABN 14 001 592 650. All rights reserved.
##CONTINUE##
Sun Microsystems plans to launch an App Store that could make Apple's look smaller than a 7-Eleven by comparison.
The server vendor hopes to increase sales and drive more business via the Java App Store, Sun CEO Jonathan Schwartz wrote on his blog Monday.
Sun is in the process of being acquired by Oracle, which has expressed a strong interest in Sun's Java technology.
An app store based on Sun's Java programming language has potential because millions of software developers already create applications with Java, which has been out since the mid-1990s.
Sun estimates Java-based software applications are already in use on over 4.5 billion computers, mobile phones and other gadgets, giving Java a huge potential market.
Schwartz indicated the app store will focus on PC users and estimated the size of the community at 1 billion.
Apple's App Store, by comparison, has already seen over a billion software downloads, despite there only being around 21 million iPhones out there, according to the company's quarterly earnings reports.
The disparity in numbers shows Java's possibilities. But if the scant attention Schwartz's app store blog post has received since it went up on Monday is any indication, Sun may be hard-pressed to mimic Apple's success.
Past deals with Google and Microsoft convinced Sun a Java App Store has potential.
In 2005, Sun agreed to distribute Google's browser toolbar alongside its popular Java Runtime Environment, the software that allows Java applications to run on Windows PCs.
The Google toolbar sits atop just about any Web browser so people can type in a search there instead of going to Google's Web site. It was offered to PC users as an optional download via the Java Runtime's automatic update mechanism.
The toolbars turned out to be a significant driver of search traffic, Schwartz said, and the update mechanism proved to be a strong distribution tool.
The second year with Google, the fee the search giant paid Sun "increased dramatically," Schwartz said.
Shortly thereafter, Microsoft outbid Google for a U.S.-only distribution deal with Sun for its MSN toolbar.
"The revenues to Sun were also getting big enough for us to think about building a more formal business around Java's distribution power - to make it available to the entire Java community, not simply one or two search companies on yearly contracts," Schwartz said.
That's what the company's Java App Store, currently codenamed Project Vector, is designed to deliver.
Wilvin Chee, head of software research at IDC in the Asia Pacific, said a Java App Store holds great potential because it will bring together Java software developers and users at a one-stop-shop.
Such a store will make Java applications easier to find and ultimately lead to the development of a more Java applications, he said.
Sun plans to allow Java application developers to submit programs to a simple Web site so the company can evaluate them for safety and content before presenting them to the Java audience. Sun will charge for distribution.
The company plans to reveal more details about the Java App Store at its JavaOne conference, which opens June 2 in San Francisco, Schwartz said.
Java is a software programming language Sun developed to make the Internet and Web browsers more interactive, such as to play online games, chat with people anywhere, calculate your mortgage interest, view images in 3D and more.
-----------------------------BY Dan Nystedt (IDG News Service)
Source：COMPUTERWORLD
Copyright 2009 IDG Communications. ABN 14 001 592 650. All rights reserved.
Learning and Improving Your Debugging Skills
Programmers spend a high percentage of the time debugging rather than writing code. You probably had some training in learning a language or framework--but how did you learn to fix the defects in your software?
##CONTINUE##
When you fell in love with programming (or at least decided it was a remunerative career), you probably thought of it as a creative endeavor. You'd design great software, write the code, and poof!—it'd work perfectly the first time.
BY Esther Schindler
Source：JAVA WORLD
Copyright, 2006-2009 Network World, Inc. All rights reserved.
##CONTINUE##
When you fell in love with programming (or at least decided it was a remunerative career), you probably thought of it as a creative endeavor. You'd design great software, write the code, and poof!—it'd work perfectly the first time.
Yeah. Right.
In the real world, you spent a bunch of your time debugging code rather than writing new stuff. I'm sure I could dig up some obscure percentage of developer time that's devoted to fixing defects rather than creating new functionality, but I doubt you need to hear a number. You can too-easily picture the days you spent looking for the Bug From Hell, and its effect on your project schedule.
Now, there's lots of ways that programmers can and do learn new software skills, whether it's reading a book, attending a tech conference, or visiting sites like JavaWorld.com. (I'm rather glad you do the latter.) However, these usually focus on tools, such as languages or frameworks, and not on meta-techniques, such as "How to find that bug in two hours instead of two days." Languages may come and go, and so will IDE debuggers, but the ability to discern under which rock your bug is hiding is one that will stay with you forever.
A large part of the skill of learning to debug is, of course, experience. That might be your own experience, or the opportunity to be A Grasshopper at the Feet of A Master Programmer. I also suspect that some people have an innate talent for troubleshooting (equally relevant to fixing a broken car as a misbehaving application), and those of us without it can only pout in envy.
However, some of this can be learned. For example, one master programmer of my acquaintance had an axiom: If you've been looking for a bug for a (relatively) long time and can't find it, he said, "You're looking in the wrong place." Obvious-sounding, but certainly true... and how often have you wasted time looking in the XYZ module when the problem was somewhere else entirely?
I asked several developers for the ways they learned or improved their debugging skills. A surprising number of them talked about their mastery of the IDE's debugger or some other tool expertise, but most of what I wanted to know is their advice on improving one's ability to fix errors. Here's a short summary of their responses.
- Be disciplined. Debugging is a process, said one developer, not a series of random events. Don't randomly tweak knobs; follow the code's execution process. Just like fixing a lawnmower, he said. Does part A get the input it needs? How about the output? If that's OK, move on.
- To improve your skills, debug other people's code rather than your own. It will be easier to see the faults in the other person's assumptions than it is to see your own. You might do this as part of a cross-peer code review and cross-peer debugging. You will develop the ability to recognize the common causes of defects more quickly, promised one developer, and teach you to recognize (and abandon) your own bad development practices.
- Pretend you're the compiler. Find and correct as many errors as you can before pressing the Compile button. While most modern IDEs include integrated debuggers (like Visual Studio's Intellisense), you'll learn less from their automation than you will from consciously examining the process. (The same way you'll never learn to spell correctly by relying on a spell checker to do all the work.)
- Learn to fix bugs as early in the development process as you can. That might mean something formalized, such as test-driven development. That also means devoting time to debugging your design instead of barreling into coding.
- Debugging is easiest when you can hold the whole system in your head. Don't make the mistake of focusing in on only one part of an application. Pay attention to the interrelationships between modules. Read the code at multiple levels of abstraction, advised one programmer. "Finding the bug is the hardest part, and it takes clear understanding of what multiple pieces of the code are doing," she said.
- Part of the same bit of advice, I think, is someone else's suggestion: gain a good understanding of the system one level down from what you are working on. "If you are debugging a system level C program, it helps to know some assembly and something about the OS," explained a system software lead engineer. "If you are debugging a J2EE app, it helps to know something about Java threads, RMI and GC." In many cases, he pointed out, error messages come from that one-level-down. "If you can understand what that means, it will help you figure out what is going wrong at your level of abstraction," he explained.
A few developers also recommended extra resources. Among them is David Agan's book, Debugging, which promises nine indispensable rules, and Why Programs Fail: A Guide to Systematic Debugging, which is about to be released in a second edition. The developer who recommended the latter says it teaches a systematic approach to debugging with plenty of hands-on examples. Another suggested an online essay, Ten skills of highly effective software testers.
I like all those answers, but I suspect there's more wisdom to be shared. How did you gain your debugging skills? How have you helped others improve theirs?
-----------------------------BY Esther Schindler
Source：JAVA WORLD
Copyright, 2006-2009 Network World, Inc. All rights reserved.
After Oracle's Sun takeover, what now for Java?
Now the dust has settled following Oracle's $7.4bn takeover of Sun Microsystems, Stuart Lauchlan looks at the legacy for the Java community and whether the firm has taken onboard lessons from its previous acquisition trail.
##CONTINUE##
Last week's shock announcement by Oracle that it was taking over long time partner Sun Microsystems left a number of questions in its wake, most notably the fate of Java. Will Oracle's ownership prove to be a boon or a bane to the wider Java movement? The answer will impact on the entire industry but opinions are still divided as to what degree and what the long-term effect will be.
-----------------------------
BY Stuart Lauchlan, news and analysis editor
Source：MYCUSTOMER.com
Copyright © 2009 Sift Media. All rights reserved.
##CONTINUE##
Last week's shock announcement by Oracle that it was taking over long time partner Sun Microsystems left a number of questions in its wake, most notably the fate of Java. Will Oracle's ownership prove to be a boon or a bane to the wider Java movement? The answer will impact on the entire industry but opinions are still divided as to what degree and what the long-term effect will be.
"If Oracle closes the Sun acquisition, the Java community could see a welcome new realignment that will place realpolitik ahead of religion," reckons Tony Bear, of research house Ovum. "Based on its BEA track record, it is evident that Oracle will likely take a dispassionate look at Sun's Java technology portfolio. Rather than wage dogmatic standards battles, Oracle will look at Sun's Java stack opportunistically."
Oracle finally acquired application server firm BEA systems in April last year following a high-profile hostile takeover bid.
A change in attitude
But its not all good news. One of the major questions surrounding Oracle's proposed acquisition of Sun is the fate of the overlapping Java-based product sets. "The problem for Sun is that although it invented Java it never profited from it," argues Bear. "Over the years, Sun became so vocal on waging standards wars that it overwhelmed its Java marketing message. We expect a quieter, more market-driven approach from Oracle.
"Based on how Oracle converged BEA's products, we expect a more realistic, nuanced strategy. As with BEA, Oracle will likely dissect the Sun Java portfolio into 'strategic', 'continue and converge', and 'maintenance' buckets, based on market presence and whether Sun's products fill any gaps. Considering that Sun never successfully marketed its Java stack, we anticipate that relatively few acquired products will be deemed strategic."
Sun's previous style of leadership over the Java Community Process (JCP) chafed key members such as IBM. Using the pretext of a battle over Java development tool GUI controls, IBM spearheaded the formation of the Eclipse Foundation in 2001, marking the emergence of the first rival power centre to the JCP. Sun later responded by forming NetBeans, but in intervening years it never attained parity with Eclipse's third-party support.
Additionally, within the JCP, Sun often found itself on the wrong side of Java Specification Requests (JSRs) debates, such as an alternative component bundling specification to the widely popular OSGi or Java Business Integration (JBI), which lacked support from the two biggest Java players (IBM and then independent BEA). Outside the JCP, there was JavaFX, Sun's shot in the dark for a JVM-native rich internet client that contended with the better known Adobe Flash and Microsoft Silverlight.
"We anticipate that Oracle will adopt a more realistic attitude towards NetBeans and Eclipse - a development that could settle this battle with a whimper rather than a bang," says Bear. "That will set the stage for more rationalised competition with IBM and JBoss/Red Hat for a development community that now has considerably more options than when IBM first spearheaded the formation of the Eclipse Foundation. Oracle's acquisition of Sun means a more realistic approach to Java portfolio and standards."
But Steven O'Grady at analyst firm Redmonk also cautions: "Oracle, like IBM, is heavily invested in a Java world, from the tools back-up to the middleware portfolio. And clearly, Oracle understands the importance of the ecosystem and is unlikely to rock the boat via draconian or dictatorial changes to the JCP. That said, it remains to be seen whether or not large Java players such as IBM will be as comfortable being strategically beholden to a clear and present danger like Oracle versus the smaller and, therefore, less threatening Sun. Could we see, for example, an IBM developer strategy that while still Java focused, incorporates rather than attacks the increasing diversity of deployment models? This acquisition is likely to have them at least asking that question."
A good Java citizen
However, Oracle has been a good Java citizen to date, suggests Gartner Group, and will be aware of the implications of rocking the boat too much. "Java is among the most valuable assets at stake in Oracle's proposed acquisition of Sun. Gartner believes that control of Java was one of the main drivers behind the deal," says Gartner Group's Massimo Pezzini. "But ownership of Java will require some diplomacy on Oracle's part. If Oracle makes over Java into a proprietary technology or dramatically increases the cost of Java licenses, it risks limiting Java's popularity and profitability. IBM, SAP and Nokia have never perceived Sun as a threat to their business in the enterprise software and mobile markets comparable to the threat potentially represented by Oracle.
The outcome, he says, could be that important Java industry participants believe Oracle has "hijacked" Java, they will strive to reduce their dependency on a technology controlled by a major competitor. "Heavily invested in Java, these companies could not afford to suddenly drop their support for it due to the large number of their customers using Java-based products and the lack of readily available alternatives," Pezzini adds. "Instead, vendors may be tempted to develop their own Java-compatible technologies."
This would raise the prospect of a fragmented Java market with different flavours. "The market could break down into the 'true' Oracle Java, IBM's derivative, an SAP variant and possibly 'open source' variants," notes Pezzini. "Such fragmentation would be catastrophic for Java as well as for Oracle, dramatically devaluating its acquisition."
But he also believes Oracle is likely to take aggressive steps to reassure the industry that it will maintain and possibly reinforce the open nature of the JCP and Java. "The IT industry values Java for its vendor-neutral and open qualities. For 15 years, users and independent software vendors have invested in Java and facilitated its adoption, due largely to the portability of Java applications across hardware platforms, operating systems, database management systems and other systems," Pezzini continues.
"Should Java technology fragment or should Oracle be perceived as 'locking in' Java to a proprietary technology, the IT industry is likely to lose its enthusiasm for Java and seek alternatives — with Microsoft as the most obvious option."-----------------------------
BY Stuart Lauchlan, news and analysis editor
Source：MYCUSTOMER.com
Copyright © 2009 Sift Media. All rights reserved.
Oracle suits to strap on Sun's Java sandals
Along with Linux, Java's been one of the biggest boons for Oracle. It's become the anchor of Oracle's middleware and developer strategy, and - with Linux - ended Oracle's one-time dependence on Microsoft as the only alternative to IBM.
##CONTINUE##
Linux Foundation executive director Jim Zemlin has said he does not see Oracle's commitment to Linux lessening just because it wants to take ownership of a Solaris business.
-----------------------------
BY Gavin Clarke in San Francisco
Source：The Register
© Copyright 1998–2009.
##CONTINUE##
Linux Foundation executive director Jim Zemlin has said he does not see Oracle's commitment to Linux lessening just because it wants to take ownership of a Solaris business.
Oracle's chief executive Larry Ellison, meanwhile, noted Java's value, calling it the most important piece of software his company has ever bought. "Oracle is now able to make all of the pieces of the technology stack fit together and work well," he said
But owning Sun - creator and steward of Java - does not mean Oracle "owns" Java in the same way it's picked up other companies customers in the past. Quite the contrary: Oracle will have to convince people its intentions are good.
For the first time in any of its many acquisitions, Oracle's getting more than products and customers along with a purchase: It's getting a cause.
Oracle will step into the lead position on the Java Community Process, the body responsible for new APIs - Java Specification Requests - in Java. Oracle will also become the lead on many JSRs that lead by Sun. That will worry those who fear Oracle has no time for community or that Oracle will only work those JSRs that are important to its middleware business.
Oracle, though, has a long history of working through industry standards bodies like OASIS and the W3C and on formats such as ODF. In fact, Oracle and Sun thought nothing of teaming up on proposed standards and specifications. Sometimes, this was big-vendor politics. Other times, this was the companies supporting the "better" proposal.
But the company is not regarded as an idealist in the same vein as Sun. Much to its chagrin, its charitable works - such as numerous contributions to the Linux kernel and work on Java - frequently get overlooked by the community, while IBM gets all the credit.
Owning the Java flag won't necessarily advantage Oracle, or its middleware. The excitement from developers in Java is in small or modular open-source frameworks and tools, typified by companies such as SpringSource - home of the Spring Framework.
The JCP has lost its authority among the people involved in this work or using these frameworks. The JCP is seen as a big-vendor talking shop. And JCP member Oracle is just another big vendor.
Furthermore, while Oracle's chief architect Ed Scrivens said this week Java is important to Oracle's middleware, Oracle is not going to get any automatic loyalty from the deal. The best it can do is set out the technology birdseed and hope developers feed periodically at its table.
Any move by Oracle to push a Java Enterprise Edition agenda through the JCP or elsewhere will not only be irrelevant, but will confirm developers suspicions and drive them further away.
As SpringSource chief executive, and Spring founder Rod Johnson blogged: "We agree with Oracle that enterprise Java has a big future. In fact, we are convinced we can help take it to the next level of productivity. But Oracle does not own that future. One of the great strengths of Java is its developer and open source community. This is something that cannot be bought in the same way as a PeopleSoft or WebLogic application server business."
SourceForge's director of community Ross Turk told The Reg Oracle's play on Java seemed to re-enforce its enterprise strategy - to provide a single-vendor solution. He also noted that he's concerned about what Oracle will do to the open-source MySQL database. SourceForge is home to 13,000 projects that use MySQL.
"In the web world people are turning to go for lighter frameworks, But in the Oracle world, applications above the database and middleware - a lot of it is still Java. It seems what they are going for is an Apple-esque single vendor solution, that you don't really get anywhere else these days," Turk said.
There is an opportunity here. Oracle's ownership of the Java "cause" and some of the mechanisms provide an opportunity to win back dissidents through a re-invigorated JCP. For all its talk of community, Sun failed to resolve a lingering licensing dispute with the Apache Software Foundation (ASF) over its implementation of Java Standard Edition.
The only question is how far Oracle - a very business-first operation - is willing to play the community card.-----------------------------
BY Gavin Clarke in San Francisco
Source：The Register
© Copyright 1998–2009.
Java looked upon as the hottest prospect
The Java programming language, developed by James Gosling, the Sun Microsystems engineer, in the 1990s as an industry standard to counter the growing influence of Microsoft, has since become a key part of the software foundation for a generation of information technology systemsOracleIBM.
##CONTINUE##
Sun, however, failed to make much of a business out of Java, even though it is used on hundreds of millions of PCs, mobile phones and other digital gadgets. Licensed cheaply and operated as an open standard, it has become a shared resource for many of the software companies that exist outside the Microsoft camp.
Yet that history belies Java's true significance, at least according to Oracle. Larry Ellison, the software company's chief executive, yesterday declared Java "the singlemost important software asset we have ever acquired" - and at a price, after deducting Sun's net cash, that is only about half the amount Mr Ellison paid for PeopleSoft, his most famous software acquisition.
Along with Solaris, Sun's Unix computer operating system, Java is the overriding reason for Oracle's decision to swoop in at the eleventh hour and make an offer of more than $7bn for the company, Mr Ellison and other Oracle executives said.
The central position of Sun's software points to how the value has shifted in its wide portfolio of technologies as its core hardware business has crumbled. Although known mainly as a maker of servers, Sun has struggled as its customers have turned to cheaper, standardised machines based on chips made by Intel and Advanced Micro Devices.
Oracle made little effort yesterday to disguise the fact that it sees Sun's hardware business as a mere afterthought. Publicly, its executives said only that they would make sure hardware became a profitable division within Oracle.
According to one person close to the company that is likely to mean forcing through the sort of aggressive cost-cutting Sun itself had resisted as an independent company, and narrowing the range of products to focus on the sort of high-end, complex systems that command the highest prices.
Oracle has already taken a step into hardware, "bundling" database software into a machine from Hewlett-Packard so it can sell a complete system. Likewise, with Sun hardware, it will sell servers along with sector-specific software aimed, for example, at retailers or banks that amount to an "industry in a box", said Charles Phillips, co-president.
Yet this ability to combine hardware and software to build complete integrated IT systems, although loudly trumpeted by Oracle executives yesterday, is not the driving force behind the deal. In fact, some Silicon Valley veterans said they expected Oracle to sell off some of Sun's hardware lines, with storage products and Sparc microprocessors at the top of the list to sell.
Rather, Oracle has its eyes set firmly on the Sun software - and combining this with Oracle's own software throws up a "wildly profitable" opportunity that should make the Sun acquisition much more valuable than any of the other deals the acquisitive company has pulled off, according to the person close to Oracle.
Part of the reason, this person says, is that Oracle believes it can make far more from Java than Sun ever did. That is because Sun decided a decade ago virtually to give the software away to make sure it was widely adopted. Many of the Java licences - including one that Sun granted to Nokia - were for 10 years and come up for renewal next year, implying that, in future, Oracle will look to extract a higher price for the technology.
However, Oracle is likely to find it hard to extract a price for Solaris, the operating system that Sun was forced to turn into an open-source product to try to hold its own against rival Linux.
The fate of Solaris is central to Oracle's future: the company sells more database software licences on Solaris than on any other operating system, Mr Ellison said.
The final big software prize is MySQL, the open-source database program Sun bought last year for $1bn. Oracle's databases handle more massive workloads, but MySQL has been adopted rapidly by next-generation web companies looking to save on cost. With Oracle in charge of MySQL, it could reap revenue from related services contracts while ensuring that the programme does not develop into a more serious rival product.
-----------------------------
BY Joseph Menn and Richard Waters
Source：The Financial Times
© Copyright The Financial Times Ltd 2009.
##CONTINUE##
Sun, however, failed to make much of a business out of Java, even though it is used on hundreds of millions of PCs, mobile phones and other digital gadgets. Licensed cheaply and operated as an open standard, it has become a shared resource for many of the software companies that exist outside the Microsoft camp.
Yet that history belies Java's true significance, at least according to Oracle. Larry Ellison, the software company's chief executive, yesterday declared Java "the singlemost important software asset we have ever acquired" - and at a price, after deducting Sun's net cash, that is only about half the amount Mr Ellison paid for PeopleSoft, his most famous software acquisition.
Along with Solaris, Sun's Unix computer operating system, Java is the overriding reason for Oracle's decision to swoop in at the eleventh hour and make an offer of more than $7bn for the company, Mr Ellison and other Oracle executives said.
The central position of Sun's software points to how the value has shifted in its wide portfolio of technologies as its core hardware business has crumbled. Although known mainly as a maker of servers, Sun has struggled as its customers have turned to cheaper, standardised machines based on chips made by Intel and Advanced Micro Devices.
Oracle made little effort yesterday to disguise the fact that it sees Sun's hardware business as a mere afterthought. Publicly, its executives said only that they would make sure hardware became a profitable division within Oracle.
According to one person close to the company that is likely to mean forcing through the sort of aggressive cost-cutting Sun itself had resisted as an independent company, and narrowing the range of products to focus on the sort of high-end, complex systems that command the highest prices.
Oracle has already taken a step into hardware, "bundling" database software into a machine from Hewlett-Packard so it can sell a complete system. Likewise, with Sun hardware, it will sell servers along with sector-specific software aimed, for example, at retailers or banks that amount to an "industry in a box", said Charles Phillips, co-president.
Yet this ability to combine hardware and software to build complete integrated IT systems, although loudly trumpeted by Oracle executives yesterday, is not the driving force behind the deal. In fact, some Silicon Valley veterans said they expected Oracle to sell off some of Sun's hardware lines, with storage products and Sparc microprocessors at the top of the list to sell.
Rather, Oracle has its eyes set firmly on the Sun software - and combining this with Oracle's own software throws up a "wildly profitable" opportunity that should make the Sun acquisition much more valuable than any of the other deals the acquisitive company has pulled off, according to the person close to Oracle.
Part of the reason, this person says, is that Oracle believes it can make far more from Java than Sun ever did. That is because Sun decided a decade ago virtually to give the software away to make sure it was widely adopted. Many of the Java licences - including one that Sun granted to Nokia - were for 10 years and come up for renewal next year, implying that, in future, Oracle will look to extract a higher price for the technology.
However, Oracle is likely to find it hard to extract a price for Solaris, the operating system that Sun was forced to turn into an open-source product to try to hold its own against rival Linux.
The fate of Solaris is central to Oracle's future: the company sells more database software licences on Solaris than on any other operating system, Mr Ellison said.
The final big software prize is MySQL, the open-source database program Sun bought last year for $1bn. Oracle's databases handle more massive workloads, but MySQL has been adopted rapidly by next-generation web companies looking to save on cost. With Oracle in charge of MySQL, it could reap revenue from related services contracts while ensuring that the programme does not develop into a more serious rival product.
-----------------------------
BY Joseph Menn and Richard Waters
Source：The Financial Times
© Copyright The Financial Times Ltd 2009.
Performance of Java Compilers: An Empirical Study
How fast should our Java code be to be considered fast?
##CONTINUE##
How fast should our Java code be to be considered fast? After all, speed is a relative concept. I'll compare the results of CPU performance for the following JVMs: Sun's J2SE 1.4.1, 1.4.0, 1.3.1, and Jikes. These results can be used to make a number of educated decisions such as choosing a JVM, deciding on algorithmic designs, and selecting the right method from the API. They provide an overall assessment of performance that's not custom related since the code used is quite common and drawn directly from Sun's Java APIs.Shirazi, J. (2003). Java Performance Tuning, 2nd Edition. O'Reilly & Associates, Inc. Wilson, S., and Kesselman, J. (2000). Java Platform Performance: Strategies and Tactics. Addison-Wesley Pub Co. http://java.sun.com/docs/books/performance/ BEA WebLogic JRockit Virtual Machine: www.bea.com/products/weblogic/jrockit/index.shtml Java 2 Platform, Standard Edition (J2SE): http://java.sun.com/j2se/ Jikes: http://oss.software.ibm.com/ developerworks/opensource/jikes/ Blackdown Project: www.blackdown.org Java BluePrints: http://java.sun.com/blueprints/enterprise/ TheServerSide.com: www.theserverside.com/patterns/index.jsp Java 2 Platform, Standard Edition (J2SE): http://java.sun.com/j2se/1.4/performance.guide.html Haggar, P. "Improving Java Code Performance": www.nejug.org/2000/sept00_slides/javaperf.htm
-----------------------------
BY Babis Marmanis
Source：SYS-CON
Haralambos (Babis) Marmanis is a pioneer in the adoption of machine learning techniques for industrial solutions, and also a world expert in supply management. He has about twenty years of experience in developing professional software. Currently, he is the director of R&D and chief architect, for expense management solutions, at Emptoris, Inc. Babis received his Ph.D. in Applied Mathematics and Scientific Computing from Brown University. Aside from machine learning and data mining, his interest is on multi-tier, high performance, enterprise software.
Copyright © 2009 SYS-CON Media. All Rights Reserved.
##CONTINUE##
How fast should our Java code be to be considered fast? After all, speed is a relative concept. I'll compare the results of CPU performance for the following JVMs: Sun's J2SE 1.4.1, 1.4.0, 1.3.1, and Jikes. These results can be used to make a number of educated decisions such as choosing a JVM, deciding on algorithmic designs, and selecting the right method from the API. They provide an overall assessment of performance that's not custom related since the code used is quite common and drawn directly from Sun's Java APIs.
This article studies the Java APIs for an extra boost in performance. It's not a new idea, and is often referred to as micro-benchmarking (MBM). However, a systematic and thorough performance analysis at that level is still missing. Herein, I'll address performance as speed, measured in wall clock time. I'll cover various Java Virtual Machines (JVMs), and show that the results differ significantly. A study of memory consumption is also warranted, but it will not be addressed here; for such an analysis, visit www.marmanis.com. See the Resources section for references to performance studies.
When dealing with performance, one of the major difficulties is the many "scales" or layers that are usually involved in Java applications, especially in enterprise Java applications. I categorize performance problems based on their scale:
- System architecture
- Algorithm selection
- Code implementation
- System configuration
- System infrastructure
Only categories 1, 2, and 3 are directly related to the Java programming language. Problems in category 1 can be dealt with or, even better, prevented, by the proper use of J2EE Blueprints, the Java version of design patterns for enterprise applications (see http://java.sun.com/blueprints/enterprise and www.theserverside.com/patterns/index.jsp). Categories 4 and 5 involve handling and testing components that may be irrelevant to Java per se. These categories are given in order of decreasing importance. Experience shows that you will get most of your performance increase from improvements in categories 1 and 2, regardless of how you measure performance! Nevertheless, if you want to squeeze as much performance as possible out of your infrastructure, it's worth knowing what the performance of your fundamental APIs is. This part of performance is aptly called micro-performance and it belongs to category 3.
Micro-Performance
This article addresses the performance of Java applications with respect to the underlying JVM, and is based only on the standard API classes and algorithms that are implemented by them. We do this in order to establish results that are widespread in their applicability. No matter what code you write, you can decompose it into parts that can be studied as individual units. The performance of the whole is equal to the performance of its parts plus the overhead of the interaction between the parts. The simplest parts that you can decompose are the classes that are offered by the Java API. Thus, knowing how well these parts perform can be crucial to the overall performance of your product.
Before we go any further, I'll justify why it's a good idea to know about micro-performance. It may be considered unnecessary to examine the performance at its finest granularity. However, most performance-tuning strategies neglect the fact that the right choice, at the micro level of the code, can squeeze out speed without making the code more complicated or error prone. Moreover, it is something that everyone can do; no special training is needed to choose the method that is the fastest of a variety of possible methods and equally effective for the task at hand.
Typically, an engineering team will employ a profiling tool that will pinpoint the location of "hotspots" (memory- and/or CPU-intensive code fragments). This is certainly a valid way of improving performance, but it says nothing about global performance. If your code throughout is slow, then a profiling tool won't help.
Global performance excellence stems from a global enforcement of best practices, i.e., fast implementations throughout the code. We would like to see extremely fast Java applications, especially enterprise applications, and our maxim is that optimal code should be used everywhere in the source code. A fitting analogy here is the saying, "A water tower can be filled one teaspoonful at a time." Best practices can be revealed by a detailed study of the available APIs and documentation of the findings. Implementing the fastest code doesn't necessarily mean the code will be more error prone; you can be fast and accurate simultaneously. I hope this article contributes toward that end.
For the purpose of illustrating micro-performance benchmarks, we will use four Java Virtual Machines. Three of them (J2SE 1.3.1_07-b02, 1.4.0_03-b04, and 1.4.1-b21) are provided by Sun Microsystems, Inc. (http://java.sun.com/j2se/), and the other (Jikes 1.3.0) is provided by IBM (http://oss.software.ibm.com/ developerworks/opensource/jikes/). One of the design guidelines for Sun's version 1.4 was to improve the performance and scalability of the Java platform; you can read more about their specific rationale at http://java.sun.com/j2se/1.4/performance.guide.html.
The bytecode for each run was created by the compiler that comes with each distribution. (The source code can be downloaded from www.sys-con.com/java/sourcec.cfm.) All the compilers were invoked as follows (see also the scripts that are provided):
%JVM_HOME%\bin\javac -g:none -O Test[i].java
where %JVM_HOME% is the path to the distribution that we target, and Test[i].java is the Java class that corresponds to one of our tests (e.g., Test2.java). The flag -O eliminates optional tables in the class files, such as line number and local variable tables. This provides only a small performance improvement on the generated code, although if our class files had been sent across a network, it could have helped significantly. IBM and Sun have no plans for bytecode optimization; they'd rather focus on runtime optimization (see www.nejug.org/2000/sept00_slides/javaperf.htm).
Once the bytecodes were created, they were executed by the target runtime:
%JVM_HOME%\bin\java -server %JVM_XMX% %JVM_XMS% Test[i]
where %JVM_HOME% is again the path to the distribution that we target, and Test[i] is the Java bytecode that corresponds to one of our tests (e.g., Test2.class). The JVMs by Sun offer the following options: client, server, and hotspot.
For the 1.4.x versions, the hotspot is a synonym for the client JVM. I've chosen to use the server JVM, although it should be easy for the user to experiment with the client JVM by changing the respective flag in the scripts. In general, the differences between the server and the client versions are related to the JVM tuning. The client JVM is tuned to reduce application startup time and memory footprint, which is important when running desktop applications. The server JVM is intended for use in server applications where the JVM will run for long times and peak performance is more important than footprint and rapid startup. Both options are of interest, although Java is clearly more prevalent on the server side.
Last, I've also chosen to fix the size of the heap in order to remove the burden of resizing the memory, which is one of the garbage collection responsibilities. This doesn't prohibit the garbage collector from doing its work. The question that we really ask is this: Given a fixed amount of memory for each JVM, which JVM performs the exact same code faster? During that time - not longer than a few minutes in the worst case - the JVM that spends the least time dealing with garbage collection will have an advantage over the other JVMs.
I'll employ only one operating system platform, namely, the Windows 2000 Professional. However, it should be clear that for a complete and useful assessment of micro-performance, the same benchmarks should be run for other operating systems as well, such as Linux, Solaris, and AIX. The Windows system that I'll use runs on a Dell Inspiron 4100, with total physical memory of 654,776KB; BIOS PLUS Version 1.10 A09; and x86 Family 6 Model 11 Intel CPU at 1,100MHz. Results for a Linux system that runs on a Micro PC, with total physical memory of 772,856KB and an AMD Athlon Processor at 1,134MHz, should be available on my Web site. For the Linux platform, there is also a JVM that's offered by the Blackdown open source project (see www.blackdown.org). There are more JVM implementations available and I'll make an effort to include as many of them as is possible on my Web site.
The Benchmarks
I'll present 19 benchmarks that cover some of the following: basic arithmetic operations, java.lang package, java.io package, java.util package, and java.security package. I refer to each test by concatenating the character "T" and the respective enumeration of the test. Thus T1 will refer to Test 1, T2 will refer to Test 2, and so on. Obviously, this is not an exhaustive list and the choices are based on what I think are popular method calls.
The code for the benchmarks was written with simplicity in mind. The theme is the same for all benchmarks. They all consist of some setup code and some code inside a for loop whose timing is the goal of each benchmark. Thus, each benchmark repeats for a "reasonable" time a call to a small piece of Java code. I use System.currentTimeMillis() to measure the wall clock time (in ms). To take into consideration the time spent for the loop, I always run a baseline test first to obtain the reference time, i.e., the time spent in a loop without code in it. Rather than subtracting the reference time from the reported value, I report both. I'll also report the number of iterations since this varies among our benchmark tests. I'll often include several method calls inside the loop so we can examine the efficacy of some API classes in an aggregate fashion; see, for example, the benchmark Test5.java. A more granular approach is, of course, what this article proposes and I'll publish and maintain on the Web more fine-grained results.
Let's now see what each test measures and analyze its results. All values refer to ms and the loop size was chosen so that I'd weed out any fluctuations of the CPU due to unrelated processes. Figure 1 shows a snapshot of the list of services that run during the test and Figure 2 shows a snapshot of the process list from the TaskManager of the Windows OS. Inside parentheses I include the ratio of performance for each JVM when compared to the Sun 1.4.1 JVM. Hence, a value smaller than 1 means that the JVM is faster than Sun's 1.4.1 JVM, and a value larger than 1 means that the JVM is slower than Sun's 1.4.1 JVM; therefore the value inside the parentheses will always be equal to 1 for the last column.
1. T1 measures the performance for typical numerical operations. I use a long and two double numbers, and perform an addition, a multiplication, and a division with constant numbers.
2. T2 defines a number of variables of type string and uses the method equals to compare them. Inside the loop I use several different string comparisons, since the speed of the algorithm is not uniform across all possible strings. Hence, my results will give a good estimate of the method's performance for strings that are equal in length or vary by one character.
3. T3 has the same setup as T2 but uses the method equalsIgnoreCase.
4. T4 has the same setup as T2 and T3 but uses the method compareTo.
5. T5 tests the performance of some commonly used mathematical functions. The class java.lang.Math has various useful mathematical functions. We test the method that creates a random number, random(); the method that calculates the cosine of an angle, cos; the method round that returns the closest long to its argument of type double; the method that calculates the absolute value of a number, abs; the methods that return the exponential and the logarithm of an argument, exp and log, respectively; the method that gives us the maximum between two numbers, max; the method that gives us the square root of a number, sqrt; and finally the method that raises one number to a certain power, pow.
6. Another common task for many applications is the reading of a properties file. This is usually done by reading the file via the java.io API and loading the values on a Properties class that's provided in the java.util package. I do just that in T6.
7. As you may very well know by now, string concatenation is much slower than the append method of a StringBuffer. T7 tests how quickly this works for the various JVMs under study. Some time is spent to find the length of the StringBuffer each time and delete all its content so that the StringBuffer is empty at the beginning of each iteration. In total, we have six append calls, one length, and one delete.
8. In T8 I measure the performance of the various classes that are needed to encrypt and decrypt a 128-character string. I use the SunJCE provider and a triple DES key spec. In particular, I initialize the Cipher with "DESede/ECB/PKCS5Padding." Jikes does not run with exactly the same code in this case, so an N/A appears in the corresponding position of the table.
9. In T9 I serialize, write to the disk, read from the disk, and deserialize a Vector object.
10. In T10 I test the performance of the method add in an ArrayList.
11. In T11 I test the performance of the method add in a Vector.
12. In T12 I test the performance of the method add in a HashSet.
13. Since the above three tests add Random objects in the various collections, I run a test, (T13), that measures the time that the generation of these objects takes. These times will be referenced side-by-side with the times that I obtain from T10, T11, and T12.
14. In T14 I test the performance of the method remove in an ArrayList.
15. In T15 I test the performance of the method remove in a Vector.
16. In T16 I test the performance of the method remove in a HashSet.
17. A typical way of iterating through the elements of a collection is by using the Iterator object. In T17, I obtain the Iterator of an ArrayList and iterate through all its elements.
18. In T18 I obtain the Iterator of a Vector and iterate through all its elements.
19. In T19 I obtain the Iterator of a HashSet and iterate through all its elements.
Conclusion
I cannot emphasize enough the importance of the data on the performance of a method call when attempting to do micro-benchmarks. The space that is usually covered by the arguments of an operation, or of a method call, is vast. Although indicative values can be obtained, the results are applicable only for the space of the arguments that they cover. With that "alert" status in mind, let's proceed and draw some conclusions.
The results for T1 (see Table 1) show that the Sun JVMs take advantage of the fact that the second operand is a constant and achieves some aggressive optimization of arithmetic operations. Nevertheless, all JVMs are quite fast and achieve billions of operations per second.
The results of T2, T3, and T4 (see Table 2) show that compareTo is two to three orders of magnitude faster than either of the equals methods. In my study - not shown here - I have found that the method call equalsIgnoreCase of the class String is a lot faster than the method call equals of the same class when the majority of the compared data have different lengths. There is a good reason for this, of course. The equalsIgnoreCase first checks the length of the two strings. Nevertheless, the point is that if you know that piece of information and you happened to extensively use string comparisons, you can take advantage of it without paying a penalty; if case does matter, then obviously this is not appropriate!
The results of T5 (see Table 3) show that the mathematical functions are two orders of magnitude faster with Jikes than with any of the Sun JVMs. Hence, if you rely heavily on computing cosines and logarithms, you should definitely take that into consideration when picking your JVM. However, the results of T6 and T7 show that there is not really a difference between the JVMs when it comes to loading a properties file and using the append method, respectively.
The results of T8 (see Table 4) show that encryption-related methods in the Sun 1.4.x JVMs are an order of magnitude faster than the same methods in Sun 1.3.1. Thus, if encrypting and decrypting is bread and butter for you, you have one more reason to upgrade your JVM!
The results of T9 (see Table 5) show that serialization to (upper readings) and deserialization from (lower readings) a file with the Sun 1.3.1 JVM is faster than any other JVM. Jikes is faster than both of the Sun 1.4.x JVMs. However, all the JVMs are in the same order of magnitude in terms of the time spent to accomplish the task.
The results of T10, T11, and T12 (see Table 6) show that the add method is equally fast for an ArrayList and a Vector. However, Jikes is faster by a factor of at least two, regardless of the Collection class that's used. A somewhat disturbing result is that the Sun 1.4.x JVMs seem to be slower than the Sun 1.3.1 JVM for the ArrayList and the Vector classes. This result consistently appeared in the runs that were made in preparation for this article, so there should be a reason for it. As we'll see later, that doesn't happen with the remove method or the iterator. It would be nice if the Sun engineers would take a look at it.
As expected, the add method in the HashSet class is slower than the same method for the ArrayList and the Vector classes. It's extremely slow in Sun 1.3.1, by three orders of magnitude when compared to all other JVMs. The removal and the iteration in the HashSet class are also slow with the Sun 1.3.1 JVM, by an order of magnitude compared to all the other JVMs.
The results of T14 and T15 (see Table 7) show that the remove method is equally fast regardless of the JVM. T16 shows that the same method is faster for a HashSet than for an ArrayList or a Vector; however, the method is an order of magnitude slower among the tested JVMs for the Sun 1.3.1 JVM.
Finally, the results of T17, T18, and T19 (see Table 8) show that the iteration with the Sun JVMs is faster than the iteration with Jikes by, at least, a factor of two; the caveat here is the problematic iteration of the HashSet, mentioned earlier.
The study presented here should not be considered complete. The purpose of this article is to distinguish the many scales that may affect the performance of Java applications, pay particular attention to what I call micro-performance, and to suggest one way to tackle the problem through detailed benchmarks of the APIs. The article demonstrates these ideas by employing a very small, but quite popular, portion of the APIs.
The performance of the Java API method calls clearly depends on the JVM. However, the differences are not uniform - you can't claim that JVM-1 is always faster than JVM-2. That in itself is not news, of course, but it is important to quantify the differences because you may find that for your own application JVM-1 is better than JVM-2, and you may want to instill micro-benchmarking in your own or your team's coding practice.
In the competitive market of enterprise applications, it's worthwhile to get as much performance as you can out of the standard APIs. To know how to get that advantage, we need to quantify the performance of the Java language at the level of its APIs. The point is that if you can get faster code without "collateral damage" - to use a, regrettably, quite fashionable term at the time of this writing - why not do it?
It was my initial desire to include the analysis of the GC output in this article; however, this would double, if not triple, its size. Nonetheless, I strongly recommend you collect such output (e.g., by using -verbose:gc as a flag to the JVM) and observe how the various JVMs collect their garbage over time. That's quite instructive. In addition, if you feel the urge to truly understand your JVM, use its optional flags as new parameters in your analysis of the results.
For any application of substantial size and complexity, a proper micro-performance tuning may produce significant speedups. Not comparable to the speedups that you can get by choosing a better architecture, or a better algorithmic approach; at the first stages of performance tuning even a factor of 10 is possible, in some cases. But when your architecture is appropriate and your algorithms optimal, it is likely that micro-tuning your application is a nice-to-have weapon in your arsenal. If you have already adopted micro-tuning during your code implementation, you're probably grinning right now in a self-satisfied manner!
Resources
-----------------------------
BY Babis Marmanis
Source：SYS-CON
Haralambos (Babis) Marmanis is a pioneer in the adoption of machine learning techniques for industrial solutions, and also a world expert in supply management. He has about twenty years of experience in developing professional software. Currently, he is the director of R&D and chief architect, for expense management solutions, at Emptoris, Inc. Babis received his Ph.D. in Applied Mathematics and Scientific Computing from Brown University. Aside from machine learning and data mining, his interest is on multi-tier, high performance, enterprise software.
Copyright © 2009 SYS-CON Media. All Rights Reserved.
The Future of the Web: I Disagree
Tim Bray, a Distinguished Engineer and Director of Web Technologies at Sun Microsystems has been interviewed by InfoQ about the future of the Web. With all my respect to Sun’s engineers, I have to disagree with some of the statements Mr. Bray made.
##CONTINUE##
He said, "Anything that discards the Back button is a step backward".
I strongly disagree that people who are used to the page-based Web apps can’t/won't learn how to live without it. But even if it is the case, you can create RIA that support Back button - just decide what application view (no page) to show when the user hits the Back button.
Here’s one more of Mr. Bray’s statements, "The whole universe runs on polling and it scales beautifully".
I don’t think so. To support server-side push an application has to keep an open socket connection that doesn’t take almost any resources most of the time. For a server, it's easier to keep open 65000 connections on the server, than repeatedly responding to multiple requests from 65000 clients when most of them return "Sorry, I don't have any new data for you".
I agree that opening a socket present issues for Web applications running behind firewalls, but still the whole polling universe doesn’t scale beautifully.
Mr. Bray continues, "Web applications are not computational intensive".
Of course, if you are using page-based applications that just show the data, there's nothing to do on the client other than, well, showing the data. But in the world of RIA, we should get into a different state of mind - you can and should treat the client's CPU as a first class citizen.
For example, our company helped Mercedes Benz in design and development of their Flex-based RIA: www.mbusa.com
. There's a bunch of interdependent rules for each car model that should enable/disable UI controls depending on the user's selection. For example, if you ordered white leather interior, you can't have yellow exterior. We've implemented the entire rule engine on the client, which makes the entire system a lot more responsive.
During one of my recent presentations, I said that if you build Flex/Java RIA utilizing fast AMF or RTMP protocols, you can bring 5000 records and keep them on the client in a split of a second.
A person from the audience asked,
"Why would I even need to keep 5000 records on the client?"
"Because you can! Of course, something like this sounds wrong for AJAX applications, but it's normal to bring 5000+ records of reference data to the client and keep them in the client’s VM so the user's application wouldn't need to do a round trip to the server to validate user's input".
If you offload the processing to the clients, you don't need to horizontally scale the servers. With RIA, you can afford to have Client/Server mentality again.
Mr. Bray believes that the direction of Web applications is moving form J2EE to PHP and Rails. He didn't make it clear for what kind of applications though. Is he talking about applications like Twitter that can go down several times a day and people will keep using it because they don't have any better choice? I've heard creator of Rails calling Java legacy, and I understand the populist nature of such a statement, but it's strange to hear this from one of Sun's higher ups.
In this case Tim Bray is right. But if you take any application that handles your money (Banking, eCommerce, auctions) I'd rather stick to tried and true J2EE on the server and the RIA client software (Flash Player, Silverlight, JavaFX) that runs inside a predictable Virtual Machine.
I believe that Web moves to a VM-based stateful clients with fast communication lines between the client and the server moving tons of strongly-typed data back and forth. This was a mouthful sentence, wasn’t it?
-----------------------------
BY Yakov Fain
Source：SYS-CON
Copyright © 2009 SYS-CON Media, Inc. All Rights Reserved.
##CONTINUE##
He said, "Anything that discards the Back button is a step backward".
I strongly disagree that people who are used to the page-based Web apps can’t/won't learn how to live without it. But even if it is the case, you can create RIA that support Back button - just decide what application view (no page) to show when the user hits the Back button.
Here’s one more of Mr. Bray’s statements, "The whole universe runs on polling and it scales beautifully".
I don’t think so. To support server-side push an application has to keep an open socket connection that doesn’t take almost any resources most of the time. For a server, it's easier to keep open 65000 connections on the server, than repeatedly responding to multiple requests from 65000 clients when most of them return "Sorry, I don't have any new data for you".
I agree that opening a socket present issues for Web applications running behind firewalls, but still the whole polling universe doesn’t scale beautifully.
Mr. Bray continues, "Web applications are not computational intensive".
Of course, if you are using page-based applications that just show the data, there's nothing to do on the client other than, well, showing the data. But in the world of RIA, we should get into a different state of mind - you can and should treat the client's CPU as a first class citizen.
For example, our company helped Mercedes Benz in design and development of their Flex-based RIA: www.mbusa.com
. There's a bunch of interdependent rules for each car model that should enable/disable UI controls depending on the user's selection. For example, if you ordered white leather interior, you can't have yellow exterior. We've implemented the entire rule engine on the client, which makes the entire system a lot more responsive.
During one of my recent presentations, I said that if you build Flex/Java RIA utilizing fast AMF or RTMP protocols, you can bring 5000 records and keep them on the client in a split of a second.
A person from the audience asked,
"Why would I even need to keep 5000 records on the client?"
"Because you can! Of course, something like this sounds wrong for AJAX applications, but it's normal to bring 5000+ records of reference data to the client and keep them in the client’s VM so the user's application wouldn't need to do a round trip to the server to validate user's input".
If you offload the processing to the clients, you don't need to horizontally scale the servers. With RIA, you can afford to have Client/Server mentality again.
Mr. Bray believes that the direction of Web applications is moving form J2EE to PHP and Rails. He didn't make it clear for what kind of applications though. Is he talking about applications like Twitter that can go down several times a day and people will keep using it because they don't have any better choice? I've heard creator of Rails calling Java legacy, and I understand the populist nature of such a statement, but it's strange to hear this from one of Sun's higher ups.
In this case Tim Bray is right. But if you take any application that handles your money (Banking, eCommerce, auctions) I'd rather stick to tried and true J2EE on the server and the RIA client software (Flash Player, Silverlight, JavaFX) that runs inside a predictable Virtual Machine.
I believe that Web moves to a VM-based stateful clients with fast communication lines between the client and the server moving tons of strongly-typed data back and forth. This was a mouthful sentence, wasn’t it?
-----------------------------
BY Yakov Fain
Source：SYS-CON
Copyright © 2009 SYS-CON Media, Inc. All Rights Reserved.
Java makes Google App Engine more mainstream
In a case of converging technologies, Google App Engine took several steps toward the mainstream on its first birthday on Tuesday at the same time that the concept of cloud computing in general is becoming more accepted.
##CONTINUE##
Cloud computing presents applications as internet-accessible services rather than software that runs on corporate servers or people's own PCs. It can mean anything from raw computing services that can be bolted together, as in the case of Amazon Web Services, to finished products such as the Picnik photo-editing site or SalesForce.com customer-management service. Google App Engine is an intermediate level, offering a general-purpose foundation.
BY Stephen Shankland, CNET News.com
Source：builder.au
Copyright © 2009 CBS Interactive, a CBS Company. All rights reserved.
##CONTINUE##
Cloud computing presents applications as internet-accessible services rather than software that runs on corporate servers or people's own PCs. It can mean anything from raw computing services that can be bolted together, as in the case of Amazon Web Services, to finished products such as the Picnik photo-editing site or SalesForce.com customer-management service. Google App Engine is an intermediate level, offering a general-purpose foundation.
Thus far, App Engine had been limited to web applications written in the Python programming language favoured internally at Google but not as much elsewhere. But on Tuesday, the top-requested App Engine feature, support for Java programs, arrived -- albeit only in a preview form initially available only to the first 10,000 developers who sign up.
"It's the language of the enterprise," said Ryan Nichols, leader of product management and marketing at Appirio, a 140-person start-up that builds software for clients who want cloud computing applications. "It allows us to have a different level of conversation with our customers."
Google announced the Java support and a handful of other new App Engine features on its blog and at a Campfire One event for developers at its headquarters in the US. As with the regular App Engine service, use within certain limits is free, but developers must pay for heavy-duty App Engine use.
Cloud advocacy
The idea of cloud computing is catching on, and Google is a major proponent. Even Microsoft, whose twin cash cows of Windows and Office today are tethered to physical machines, plans cloud-based versions of both those products.
About 150,000 developers have built 50,000 applications on App Engine so far, Google said, and those apps draw about 100 million page views per day. The most popular is BuddyPoke, which provides social networking sites with an application that people add and control avatars. It's got 35 million users, and meanwhile, BestBuy, eBay and Forbes "have started to outsource pieces" of their computing operations to App Engine, said Graham Spencer, a Google engineering director.
Cloud computing can bring penalties such as primitive user interfaces, long waits for services to respond, and problems when the network is down or unavailable. In-house computing systems aren't infallible, but when cloud computing services fail, customers are beholden to another company's skills at restoring them.
But all these areas are being addressed, and cloud computing has some advantages, too. Online documents can more easily be shared or collaboratively authored. Applications are available from a variety of computers and mobile devices. And for those willing to yield control, another company bears the burdens of system management and data backup.
Google also announced a handful of other developments that make App Engine more useful for regular programmers:
- Through a feature called Secure Data Connector, App Engine can incorporate private data stored servers behind company firewalls, said App Engine product manager Andrew Bowers. For example, information from a company's sales database can be retrieved by App Engine and displayed in a Google Docs chart.
- Using a command called "cron", App Engine can perform some automated actions timed in advance to take place, such as collecting daily statistics and emailing them to an administrator, Bowers said.
- App Engine is getting better tools for import and, later this week, export, so it's easier to move information stored in conventional databases to App Engine and back, said App Engine product manager Mike Repass. For example, custom instructions can be applied to help convert the data.
Java: a natural fit
Sun Microsystems first released Java in 1995 as a way to add pizzazz to websites, but it caught on commercially as a way to run server software such as online banking applications. Java's design insulates software from the particulars of the hardware it's running on, so in a way building it into Google App Engine is a natural extension of the technology.
However, there are differences. On the plus side, running Java programs on App Engine means administrators won't have to worry about whether they have enough servers to handle a spike in traffic.
But because App Engine stores data with Google's BigTable technology rather than the conventional SQL databases, programmers will have to use newer interfaces such as Java Data Objects (JDO) or the Java Persistence API (JPA) rather than the older Java Database Connectivity (JDBC) standard, said Kevin Gibbs, App Engine's technical leader.
Google also brought another tool to bear in the Java support: Google Web Toolkit, which converts Java software into the JavaScript code that lets websites use to power interactive applications.
The new version 1.6 of the open-source GWT software lets programmers use the Eclipse programming tool to write a single Java application -- both the back-end processing and the JavaScript web interface -- in one fell swoop, said Bowers, who also is a GWT program manager.
Google aims to comply with Java standards, though it offered cautionary words about the preliminary nature of App Engine's Java support. It hasn't passed Sun's Java certification tests, and Google wouldn't comment on whether it plans to do so or on whose Java foundation it actually uses under the covers.
Overall, programming Java on Google App Engine should look more familiar than not to Java programmers, Gibbs said. IBM, for example, demonstrated moving an App Engine Java program to its own WebSphere software using Big Blue's DB2 database.
"Hopefully, it'll be a matter of months when any Java developer can use it and be really satisfied," Gibbs said.
-----------------------------BY Stephen Shankland, CNET News.com
Source：builder.au
Copyright © 2009 CBS Interactive, a CBS Company. All rights reserved.
Intel announces new CPU line
POSTED BY
Admin
AT
9:47:00 AM
Labels:
Acer,
Google,
Hardware News,
Intel,
JAVA,
Market News,
Security
Code-named Jasper Forest, the new microprocessor is aimed for storage products and embedded applications. Also, Java is added to Google Apps.
##CONTINUE##
Intel unveils Jasper Forest
Intel announced a new microprocessor aimed at storage products and embedded applications at the Intel Developer Forum in Beijing on Wednesday. The processor, code named Jasper Forest, is a variant on the Nehalem server processor. Intel has optimized it for embedded systems by integrating the input/output hub right onto the processor, rather than keeping it in a separate chip. At the same event, the company also announced two additions to its family of Atom processors, which are used in many netbooks. The faster of the two, the Z550, will run at 2 gigahertz, and is intended for mobile internet devices, Intel said.
Java added to Google Apps
Google has updated its Google App Engine platform, adding preliminary support for industry-standard Java applications. Only the first 10,000 developers to sign up will get access to the Java server while Google smooths out the wrinkles. Google says that its support for Java on App Engine will make it easy for developers to roll out their work to all standard J2EE servlet containers, including IBM WebSphere, Tomcat and others
Fake security software major malware threat
Fake security software programs were one of the biggest online threats encountered by Internet users in the last half of 2008, according to Microsoft's latest security report. The bogus security software programs often offer a free scan that falsely says a user's computer is infected. If installed, the programs are ineffective against malicious software. Security experts have theorized that those behind the programs reap lucrative profits. Microsoft detected two Trojan horse programs masquerading as security software on more than 3 million computers in the last six months of 2008. With the Washington state attorney general, Microsoft launched eight lawsuits in September 2008 aimed at tracking down those responsible for perpetrating the scams.
Acer hones in on niche markets
Acer is aiming at smaller and smaller demographic slices of the PC market with the two dozen products it launched Tuesday, ranging from wide-screen, all-in-one PCs to tiny nettops. Despite the focus on low-priced products, the company’s margins are staying the same, while those of competitors are falling, according to Acer CEO Gianfranco Lanci. Among the new products was a netbook with an 11.6-inch screen. Acer will continue to offer Windows XP on its netbooks, although notebook models will run Vista and, when it is released, Windows 7.
And those are the top stories from the IDG Global IT News Update, brought to you by the IDG News Service. I’m Peter Sayer in Paris. Join us again later for more news from the world of technology.
-----------------------------
BY IDG News Service
Source：itbusiness.ca
© 2009 ITworldcanada.com - All rights reserved.
##CONTINUE##
Intel unveils Jasper Forest
Intel announced a new microprocessor aimed at storage products and embedded applications at the Intel Developer Forum in Beijing on Wednesday. The processor, code named Jasper Forest, is a variant on the Nehalem server processor. Intel has optimized it for embedded systems by integrating the input/output hub right onto the processor, rather than keeping it in a separate chip. At the same event, the company also announced two additions to its family of Atom processors, which are used in many netbooks. The faster of the two, the Z550, will run at 2 gigahertz, and is intended for mobile internet devices, Intel said.
Java added to Google Apps
Google has updated its Google App Engine platform, adding preliminary support for industry-standard Java applications. Only the first 10,000 developers to sign up will get access to the Java server while Google smooths out the wrinkles. Google says that its support for Java on App Engine will make it easy for developers to roll out their work to all standard J2EE servlet containers, including IBM WebSphere, Tomcat and others
Fake security software major malware threat
Fake security software programs were one of the biggest online threats encountered by Internet users in the last half of 2008, according to Microsoft's latest security report. The bogus security software programs often offer a free scan that falsely says a user's computer is infected. If installed, the programs are ineffective against malicious software. Security experts have theorized that those behind the programs reap lucrative profits. Microsoft detected two Trojan horse programs masquerading as security software on more than 3 million computers in the last six months of 2008. With the Washington state attorney general, Microsoft launched eight lawsuits in September 2008 aimed at tracking down those responsible for perpetrating the scams.
Acer hones in on niche markets
Acer is aiming at smaller and smaller demographic slices of the PC market with the two dozen products it launched Tuesday, ranging from wide-screen, all-in-one PCs to tiny nettops. Despite the focus on low-priced products, the company’s margins are staying the same, while those of competitors are falling, according to Acer CEO Gianfranco Lanci. Among the new products was a netbook with an 11.6-inch screen. Acer will continue to offer Windows XP on its netbooks, although notebook models will run Vista and, when it is released, Windows 7.
And those are the top stories from the IDG Global IT News Update, brought to you by the IDG News Service. I’m Peter Sayer in Paris. Join us again later for more news from the world of technology.
-----------------------------
BY IDG News Service
Source：itbusiness.ca
© 2009 ITworldcanada.com - All rights reserved.
ESC SV 2009 PREVIEW: Why can't C be more like Java, C# and C++ (or vice versa)?
Many embedded developers have long been reluctant to migrate from tried and true C programming to newer programming languages such as C++, Java and C#, which support object-oriented reusable data structures implemented with design patterns to make them more reliable, more portable, and more maintainable.
##CONTINUE##
According to Michel de Champlain, the reason that the linga franca for embedded systems programmers continues to be the C programming language is simple: it is fast and it is compact.
But, he said, there are ways to stay with the well-tested and reliable C language, but still take advantage of some of the advantages of newer languages and without the problems, or the long learning curve. This is the subject of "Small and Reusable Object-Oriented Data Structures in C (ESC-464)" a class that he and Brian G. Patrick are conducting at the Embedded Systems Conference in Silicon Valley.
BY Bernard Cole
Source：Embedded.com
Copyright © 2009 TechInsights, a Division of United Business Media LLC All rights reserved.
##CONTINUE##
According to Michel de Champlain, the reason that the linga franca for embedded systems programmers continues to be the C programming language is simple: it is fast and it is compact.
But, he said, there are ways to stay with the well-tested and reliable C language, but still take advantage of some of the advantages of newer languages and without the problems, or the long learning curve. This is the subject of "Small and Reusable Object-Oriented Data Structures in C (ESC-464)" a class that he and Brian G. Patrick are conducting at the Embedded Systems Conference in Silicon Valley.
"The successors of C have extended the language, adding object-orientation in C++ and then a virtual machine in Java and C#," he said. "These features provide additional levels of abstraction which isolate, as much as possible, the programmer from the idiosyncrasies of the underlying architecture. From a software engineering point of view, these features are welcome news.
But from an embedded systems point of view, they are often cumbersome, bloated, and ill-equipped for lower level program development. "This is somewhat ironic since Java was originally conceived as an embedded systems language," he said."Equally ironic, C and C++ do not provide standard support for some basic embedded systems tasks.
"Among these tasks is memory access where embedded systems developers are often forced to incorporate language extensions offered by compiler vendors that permit all kinds of memory accesses or allocations via banks and data/code sections."
In their class, said Champlain, the focus is on the benefits of C object-oriented collections especially designed and optimized for small footprint embedded systems. "These collections also profit from a uniform memory model layer that facilitates porting across different platforms."
"By supporting code reuse, collections not only reduce memory requirements but also shorten the development time and effort for embedded systems applications," he said.
Historically, according to Champlain, modeling and programming small embedded systems has been almost impossible to tackle with an object-oriented approach. "Using classes and objects was simply too demanding for the limited space and processing power of the 8-bit microcontroller, the fundamental building block of embedded systems<" he said.
"For that reason (and a good reason at that), the majority of embedded systems programmers continue to use C as their programming language of choice," he said. "It is compact, it is quick, and it is widely-supported. However, by adopting C, we have no option but to adopt a traditional procedural approach to programming.
Although C is also versatile and allows us to emulate more modern programming paradigms or styles, such as the object-based or object-oriented approach, said Champlain, doing so often requires sophisticated programming techniques. Yet, the motivation for developing collections in an object-oriented (OO) way supports one fundamental advantage: write once for all and reuse often.
Over the last decade or so, the development of software applications has relied more and more heavily on code reuse. However, code reuse depends on two fundamental requisites: a uniform memory model that hides away the details of the underlying architecture and a class structure which encapsulates data and its behavior into a single syntactic unit.
In this class, Champlain and Patrick present the case for using C to successfully to implement abstract data types, an important step forward. But to adopt an object-oriented paradigm, languages such as B# are needed.
Designed with the embedded systems programmer in mind, the B# language is fully object-oriented and has standard support for processor interrupts, device register names, deterministic memory defragmentation, and multi-threading.
To support these features, he said, B# is coupled with its own virtual machine which promotes reusability across different hardware platforms and provides a uniform memory model.
As a result, said Champlain, the embedded systems developer is able to write interrupt handlers and access device registers in a uniform manner, independent of the underlying architecture (memory-mapped or port-mapped). "More importantly, the virtual machine of B# has been purposely designed to work within the computational and memory constraints of small footprint embedded systems," he said.
"Although memory access is a typical embedded systems requirement, it is not standard in programming languages like C, C++, Embedded C++, and Java," he said. "In these languages, conditional compilations or special keywords are often used to support several microcontroller families.
"This makes applications hard to maintain and harder still to port. Our collections submerge hardware differences based on a uniform memory model. The end result is more reusable code which is platform-independent."
The model they use manages the data and the runtime stack of an embedded application as part of a B# embedded virtual machine (VM), dedicated to small footprint embedded systems or more specifically, for 8- or 16- bit microcontrollers with a maximum memory size of 64K bytes. The virtual machine manages all memory allocations, deallocations, and defragmentations and provides an independent memory manager written in ANSI C.
"Code reuse eliminates the re-implementation of common data structures such as stacks and queues," said Champlain. "Although code reuse is possible in C, it is best exploited using an object-oriented approach and a uniform memory model built into a virtual machine.
"Therefore, languages such as B# offer an appealing alternative as code reuse play an increasingly important role in the development of embedded systems applications."
BY Bernard Cole
Source：Embedded.com
Copyright © 2009 TechInsights, a Division of United Business Media LLC All rights reserved.
Google Java release expected on April 7
Google is holding a “Campfire One” developer meeting on the lawn outside its headquarters on April 7, fuelling speculation that the company will announce a major software release.
##CONTINUE##
Commentators say the firm is likely to announce the release of Java on AppEngine, an extension to its app-building platform that will allow developers to write programs in the Java language.
The lawn is Google’s usual venue for unveiling new products.
-----------------------------
BY Jasper Jackson (Reporter)
Source：MarketClusters
© 2009 MarketClusters All Rights Reserved.
##CONTINUE##
Commentators say the firm is likely to announce the release of Java on AppEngine, an extension to its app-building platform that will allow developers to write programs in the Java language.
The lawn is Google’s usual venue for unveiling new products.
-----------------------------
BY Jasper Jackson (Reporter)
Source：MarketClusters
© 2009 MarketClusters All Rights Reserved.
How to Simplify MDD to Speed Java Enterprise Development
A notable problem of Java Enterprise Development is its inherent complexity. Also if you use Java EE standard or Spring, your development team will never be as productive as a VisualBasic, PHP, Ruby&Rails, 4GL or even COBOL development team. The complexity of Java Enterprise requires very skilled developers, moreover these developers need to write a lot of code.
##CONTINUE##
The ideal solution for this problem could be the Model-Driven Development approach. Basically MDD states that just the model part of an application has to be developed, and the rest of the application will be generated from this model. In this way, the developers write less and simpler code, nevertheless a Java Enterprise Application is created.
However, for today, MDD usage is still very complex. It needs a big investment of time, expertise, and tooling; usually building your own DSLs and combining them into a software factory, and it takes a lot of effort. Therefore, only big companies can afford MDD, and it can only be paid back when using it multiple times for different projects. And, of course, MDD is a hard alternative for mid-size and small companies.
Fortunately you can enjoy the benefits of MDD without any pain. Just remove MDA, DSLs, UML and code generation from MDD and you'll obtain a simple but effective way to do Model Driven Development.
The Better Software with Less Code white paper examines how to do Model Driven Development in a lightweight way, so it could be affordable for small and mid-size companies, and cheaper for the big ones.
-----------------------------
BY Javier Paniza
Source：SYS-CON
Copyright © 2009 SYS-CON Media, Inc. All Rights Reserved.
##CONTINUE##
The ideal solution for this problem could be the Model-Driven Development approach. Basically MDD states that just the model part of an application has to be developed, and the rest of the application will be generated from this model. In this way, the developers write less and simpler code, nevertheless a Java Enterprise Application is created.
However, for today, MDD usage is still very complex. It needs a big investment of time, expertise, and tooling; usually building your own DSLs and combining them into a software factory, and it takes a lot of effort. Therefore, only big companies can afford MDD, and it can only be paid back when using it multiple times for different projects. And, of course, MDD is a hard alternative for mid-size and small companies.
Fortunately you can enjoy the benefits of MDD without any pain. Just remove MDA, DSLs, UML and code generation from MDD and you'll obtain a simple but effective way to do Model Driven Development.
The Better Software with Less Code white paper examines how to do Model Driven Development in a lightweight way, so it could be affordable for small and mid-size companies, and cheaper for the big ones.
-----------------------------
BY Javier Paniza
Source：SYS-CON
Copyright © 2009 SYS-CON Media, Inc. All Rights Reserved.
Java: Coming Soon to Google’s App Engine
Google will soon announce comprehensive support for the Java programming language on its Google App Engine (GAE) offering. We are trying to get more details. Rumors of such a development emerged last year, but we can now confirm that it is going to happen. We have have confirmed the news and expect the announcement later this spring, perhaps at the much-vaunted Google I/O event on May 27-28th at the Moscone Center in San Francisco. A Google spokesperson declined to comment.
##CONTINUE##
What does this mean? GAE currently is a Python-only app hosting environment and Java has been one of its most-requested features. Google’s support would help Java hosting get a mainstream push. Thus far most people have pushed PHP, Perl or Rails-related hosting services. I wouldn’t be surprised if Google uses a variant of its own Java VM, code-named Dalvik, which is currently being used in Android and Google Mobile OS. Dalvik is a non-Sun-licensed Java environment.
With this Java support, Google can actually turn GAE into the cornerstone of all Android-related apps in addition to getting traction as a platform for many custom enterprise apps written in Java. But in order for all that to happen, Google would have to kick off with what has to be more than just a very barebones environment.
BY Om Malik
Source：GIGaom
© 2009 The GigaOM Network.
##CONTINUE##
What does this mean? GAE currently is a Python-only app hosting environment and Java has been one of its most-requested features. Google’s support would help Java hosting get a mainstream push. Thus far most people have pushed PHP, Perl or Rails-related hosting services. I wouldn’t be surprised if Google uses a variant of its own Java VM, code-named Dalvik, which is currently being used in Android and Google Mobile OS. Dalvik is a non-Sun-licensed Java environment.
With this Java support, Google can actually turn GAE into the cornerstone of all Android-related apps in addition to getting traction as a platform for many custom enterprise apps written in Java. But in order for all that to happen, Google would have to kick off with what has to be more than just a very barebones environment.
Even in its basic installation, Google should offer a Java environment that can be leveraged by Android app developers, who can host their apps off the GAE. An integration with Google Voice API would make the App Engine even more useful, as app developers could start building special apps for, say, Google Android-based netbooks and have them run off the Google App Engine.
Most importantly, our developer friends believe that it would be good for Google to integrate this GAE-based Java environment with the Eclipse development environment. Google announced its App Engine in May 2008 and quickly attracted about 150,000 developers. However, many developers seem to prefer the more flexible Amazon Web Services, which recently started supporting the Eclipse development environment.
-----------------------------BY Om Malik
Source：GIGaom
© 2009 The GigaOM Network.
Subscribe to:
Posts (Atom)
Posts
