Richard Davies wrote: The UK has a good crop of technology pioneers in cloud computing - for example ElasticHosts, FlexiScale, Flexiant, OnApp - and also some strong government initiatives such as G-Cloud.
We will have to see whether this kind of technical leadership converts into swift mass-market adoption or not.
The next major revision to the Java platform and language, version 1.5.0, is now available.
J2SE 1.5 has been developed under the Java Community Process as Java Specification Request (JSR) 176, which is led by Sun and an expert group of industry-recognized corporate and individual developers.
The JSR recently won a unanimous vote in the JCP Executive Committee, making way for the beta program to officially open, and accept participants immediately.
New features incorporated since the last "major" release - 1.4.0. - include:
New language updates: Metadata, Generics, Enumerated types, Autoboxing of primitive types
New JVM Monitoring and Mangement API
Improved out-of-box performance
New (but compatible) default Java look and feel
"Java technology gives developers the best platform for innovation and ease of development," said Mark Bauhaus, Sun's vice president, Java Web Services, announcing the release.
"J2SE 1.5 marks a tremendous achievement for the Java development community, and is a key milestone in the Java technology roadmap," he continued. "These Java programming language enhancements appeal to a broad variety of Java developers by harnessing the power of the Java platform and allowing developers greater to access it."
Monitoring and manageability is a key focus for the release, Bauhaus pointed out, adding that 1.5 features improvements that allow Java technology-based applications created on the J2SE 1.5 platform to be deployed into existing SNMP-based enterprise management systems.
"This allows the JVM software to be monitored and managed for higher levels of reliability, availability, and serviceability," he explained.
Also new in J2SE 1.5 platform is the inclusion of the Java Management Extensions (JMX), delivering out-of-the-box deployment to enterprise management systems that support JMX.
For more information on Java 2 Platform, Standard Edition 1.5.0 Beta 1and to participate in the beta program, visit here.
About Java News Desk JDJ News Desk monitors the world of Java to present IT professionals with updates on technology advances, business trends, new products and standards in the Java and i-technology space.
Reader Feedback: Page 1 of 1
#8
Jesse Houwing commented on 12 Feb 2004
[quote]There is still something important in my mind that Sun is still missing about the "import" directive, I think it will be very nice if I could write it as following: import java.awt.**; The double star means that it will import every class and every Package [/quote]
this would not work, as the number of classes starting with java* or any other prefix might differ between systems. This will most likely introduce namingconflicts that did not exist on the system of the original developer.
#7
Chris Nelson commented on 10 Feb 2004
I add all imports explicitly. Do not use * at all. When using date define the whole class path each instance. These rules enhance maintainability. I agree 100% with Bob Corrick.
I might start without importing at all, for example:
java.util.Date someUsefulDate; /* This can also be used to refer to a java.sql.Date - which is a subclass of java.util.Date of course. */
When the code repeats itself (eg needs another date reference), it can import just that class or interface, as Tilman suggests. Sometimes the code may end up with repetition of text such as "import java.util." - but it would be explicit, hence easier to maintain. (Easier to identify and delete those unused imports!)
A class that is having ''namespace issues'' (eg must handle both forms of Date) may benefit from refactoring or splitting, to work at one or another level of abstraction.
#5
Tilman Sporkert commented on 6 Feb 2004
Regarding the java.util.Date issue... just add a specific
import for that class, i.e.
import java.util.*;
import java.sql.*;
import java.util.Date;
Now you can say
Date myDate;
and it will resolve to java.util.Date;
#4
Francisco commented on 6 Feb 2004
Mr. Sibai... pardon my doubt of your sanity, but... are you clinically insane? Have you thought about the logical implications AT ALL?
Consider: import java.util.* and java.sql.* both include a Date class, which requires that the programmer specify java.util.Date instead of Date - every time. That's annoying and suboptimal - and you're asking for EVERY POSSIBLE namespace collision that Java can offer... all in the name of a little bit of convenience so you don't have to bother to, you know, learn Java.
Yuck.
#3
Mohamad M. Jamil Sibai commented on 6 Feb 2004
There is still something important in my mind that Sun is still missing about the "import" directive, I think it will be very nice if I could write it as following:
import java.awt.**;
The double star means that it will import every class and every Package located in java.awt, where it is still being written just like the following:
import java.awt.*;
import java.awt.event.*;
not bad for me but it should be exist in the JDK as a powerful programming environment, and consider for the easyness of writing a program:
import java.**;
it is less powerfull I know but its really needed by many programmers.
#2
I Hasan commented on 6 Feb 2004
Dan, consider yourself lucky...
we're still stuck on iplanet 4, jdk 1.2.2 !!!
Jesse Houwing wrote: [quote]There is still something important in my mind that Sun is still missing about the "import" directive, I think it will be very nice if I could write it as following: import java.awt.**; The double star means that it will import every class and every Package [/quote]
this would not work, as the number of classes starting with java* or any other prefix might differ between systems. This will most likely introduce namingconflicts that did not exist on the system of the original developer.
Chris Nelson wrote: I add all imports explicitly. Do not use * at all. When using date define the whole class path each instance. These rules enhance maintainability. I agree 100% with Bob Corrick.
Bob Corrick wrote: I might start without importing at all, for example:
java.util.Date someUsefulDate; /* This can also be used to refer to a java.sql.Date - which is a subclass of java.util.Date of course. */
When the code repeats itself (eg needs another date reference), it can import just that class or interface, as Tilman suggests. Sometimes the code may end up with repetition of text such as "import java.util." - but it would be explicit, hence easier to maintain. (Easier to identify and delete those unused imports!)
A class that is having ''namespace issues'' (eg must handle both forms of Date) may benefit from refactoring or splitting, to work at one or another level of abstraction.
Tilman Sporkert wrote: Regarding the java.util.Date issue... just add a specific
import for that class, i.e.
import java.util.*;
import java.sql.*;
import java.util.Date;
Now you can say
Date myDate;
and it will resolve to java.util.Date;
Francisco wrote: Mr. Sibai... pardon my doubt of your sanity, but... are you clinically insane? Have you thought about the logical implications AT ALL?
Consider: import java.util.* and java.sql.* both include a Date class, which requires that the programmer specify java.util.Date instead of Date - every time. That's annoying and suboptimal - and you're asking for EVERY POSSIBLE namespace collision that Java can offer... all in the name of a little bit of convenience so you don't have to bother to, you know, learn Java.
Yuck.
Mohamad M. Jamil Sibai wrote: There is still something important in my mind that Sun is still missing about the "import" directive, I think it will be very nice if I could write it as following:
import java.awt.**;
The double star means that it will import every class and every Package located in java.awt, where it is still being written just like the following:
import java.awt.*;
import java.awt.event.*;
not bad for me but it should be exist in the JDK as a powerful programming environment, and consider for the easyness of writing a program:
import java.**;
it is less powerfull I know but its really needed by many programmers.
Swisscom, the Swiss telecom, is going into the cloud business.
Its subsidiary Swisscom IT Services AG has signed up with Red Hat as a Certified Cloud Provider and launched a public cloud Infrastructure-as-a-Service (IaaS) cloud targeting enterprise-class customers primarily in ...
Apache Deltacloud, the Red Hat-contributed ReSTful API that abstracts differences between clouds so services on any cloud can be managed – provided of course there’s a driver – has graduated from the Apache Foundation’s incubator and is now a full-fledged Top-Level Project (TLP)....
In a surprise move on Tuesday, January 10, Oracle wheeled out its Big Data Appliance.
That’s the one it said in October would be ready sometime in the first half. Only nobody believed it meant early in the first half. Heck, it’s not even clear anybody thought Oracle could make ...
Rackspace Hosting, the service leader in cloud computing, on Thursday announced its acquisition of SharePoint911, an industry leader in SharePoint consulting, training, and "JumpStart" services within SharePoint. The unification of both companies provides capabilities to deliver ...
CloudLinux, Inc., on Thursday released CafeFS 3, a virtualized file system for shared hosters that cages each customer within its own virtualized file system.
CageFS becomes part of CloudLinux OS at no additional charge. CloudLinux OS, the only commercially-supported Linux OS m...