Java SE 6 Update 14 (1.6.0_14)
This release is Windows 7 support-ready and includes support for Internet Explorer 8, Windows Server 2008 SP2, and Windows Vista SP2. New features include the G1 garbage collector, plus performance and security enhancements.
Monday, June 1, 2009
Friday, May 22, 2009
Why an Application Grid?
Application servers, those dependable workhorses that run most enterprise Java applications, are rarely a hot topic of conversation these days. As a technology category, the application server appears to be fairly “established” and that the focus has moved elsewhere in the stack, but appearances can be deceiving.
Wednesday, April 22, 2009
Thursday, April 9, 2009
Free Web Application Container (Java, Servlet JSP, ...) on Google Cloud available...
Google has released today a beta of AppEngine for Java, that is a Hosted Web Application Container (Java, Servlet JSP, ...) on the Google Cloud.
Google described it as "With App Engine, you can build web applications using standard Java technologies and run them on Google's scalable infrastructure. The Java environment provides a Java 6 JVM, a Java Servlets interface, and support for standard interfaces to the App Engine scalable datastore and services, such as JDO, JPA, JavaMail, and JCache.":
The Google App Engine uses the Java Servlet standard for web applications. You provide your app's servlet classes, JavaServer Pages (JSPs), static files and data files, along with the deployment descriptor (the web.xml file) and other configuration files, in a standard WAR directory structure.
The Java Virtual Machine runs in a secured "sandbox" environment to isolate your application for service and security. The sandbox ensures that apps can only perform actions that do not interfere with the performance and scalability of other apps. For instance, an app cannot spawn threads, write data to the local file system or make arbitrary network connections. An app also cannot use JNI or other native code. The JVM can execute any Java bytecode that operates within the sandbox restrictions.
The Google AppEngine is limited in the Free version for CPU (50 CPU Hours/Day), Network Bandwith/Usage (10 GB each day), Email (2000 emails a day) but is available through billing additional quota (CPU, bandwidth in/out, storage, and e-mail) if necessary.
Google described it as "With App Engine, you can build web applications using standard Java technologies and run them on Google's scalable infrastructure. The Java environment provides a Java 6 JVM, a Java Servlets interface, and support for standard interfaces to the App Engine scalable datastore and services, such as JDO, JPA, JavaMail, and JCache.":
The Google App Engine uses the Java Servlet standard for web applications. You provide your app's servlet classes, JavaServer Pages (JSPs), static files and data files, along with the deployment descriptor (the web.xml file) and other configuration files, in a standard WAR directory structure.
The Java Virtual Machine runs in a secured "sandbox" environment to isolate your application for service and security. The sandbox ensures that apps can only perform actions that do not interfere with the performance and scalability of other apps. For instance, an app cannot spawn threads, write data to the local file system or make arbitrary network connections. An app also cannot use JNI or other native code. The JVM can execute any Java bytecode that operates within the sandbox restrictions.
The Google AppEngine is limited in the Free version for CPU (50 CPU Hours/Day), Network Bandwith/Usage (10 GB each day), Email (2000 emails a day) but is available through billing additional quota (CPU, bandwidth in/out, storage, and e-mail) if necessary.
Friday, April 3, 2009
IBM-Sun accord, what's up for Java, ... ?
According to the Wall Street Journal, IBM is in talks to buy out Sun.
Sun has been a real great promoter of Open Source Technology so far (Java, Netbeans Glassfish, MySQL, OpenOffice, ...) and has also great worthwhile technologies like ZFS (File Management System), Solaris/OpenSolaris, VirtualBox, Cloud infrastruture (Jini and other technologies...), ...
The merge between IBM will give certainly great opportunity for IBM in the domain of Virtualization and Clouds computing/storage.
IBM has been more focused on the business aspects while Sun has been more involved in High Technologies Innovations.
The Sun real value is not reflected in the Nasdaq Stock Market, but Sun has always been a real visionary company with very talented technical people (Network and distributed computing, ...) .
Is the right thing to do for Sun ?
IBM has great products as well, but are certainly sometime in competition with the Sun portfolio (Eclipse/Netbeans, WebSphere/Glassfish, AIX/Solaris, ...).
What will be the future of the Sun technology in this context ?
Java will surely survive as it is, IBM is a great sponsor of the technology.
Netbeans compared to Eclipse is much simpler to manage and maybe should be simply improved (Performance maybe principally) and extended, through plugins, to support the IBM specific products.
Glassfish already with the version V3 Prelude allows to extend the platform with modular approach based on OSGi which is already used in many different context.
Solaris and Open Solaris are already supported on the IBM hardware and are very important products in Open Source field compared to AIX. Do IBM need to extend AIX with ZFS and other technologies or to adopt Solaris as a foundation for futur AIX ?
I hope that the fusion between IBM and Sun will bring innovations to both side with real Open Source strategy for the products foundation and keep a margin of 12/18 months for commercial product based on the Open Source ones like for Glassfish ...
What impacts do you think IBM taking over Sun would have on Sun and Open Source Technologies ?
Sun has been a real great promoter of Open Source Technology so far (Java, Netbeans Glassfish, MySQL, OpenOffice, ...) and has also great worthwhile technologies like ZFS (File Management System), Solaris/OpenSolaris, VirtualBox, Cloud infrastruture (Jini and other technologies...), ...
The merge between IBM will give certainly great opportunity for IBM in the domain of Virtualization and Clouds computing/storage.
IBM has been more focused on the business aspects while Sun has been more involved in High Technologies Innovations.
The Sun real value is not reflected in the Nasdaq Stock Market, but Sun has always been a real visionary company with very talented technical people (Network and distributed computing, ...) .
Is the right thing to do for Sun ?
IBM has great products as well, but are certainly sometime in competition with the Sun portfolio (Eclipse/Netbeans, WebSphere/Glassfish, AIX/Solaris, ...).
What will be the future of the Sun technology in this context ?
Java will surely survive as it is, IBM is a great sponsor of the technology.
Netbeans compared to Eclipse is much simpler to manage and maybe should be simply improved (Performance maybe principally) and extended, through plugins, to support the IBM specific products.
Glassfish already with the version V3 Prelude allows to extend the platform with modular approach based on OSGi which is already used in many different context.
Solaris and Open Solaris are already supported on the IBM hardware and are very important products in Open Source field compared to AIX. Do IBM need to extend AIX with ZFS and other technologies or to adopt Solaris as a foundation for futur AIX ?
I hope that the fusion between IBM and Sun will bring innovations to both side with real Open Source strategy for the products foundation and keep a margin of 12/18 months for commercial product based on the Open Source ones like for Glassfish ...
What impacts do you think IBM taking over Sun would have on Sun and Open Source Technologies ?
Wednesday, March 25, 2009
Java / OSGi and Maven
I would be pleased to see standard container for services coming into place in mobile (OSGi) as well as entreprise application server (e.g.: Java EE (Glassfish)).
OSGi and the future Java 7 include such functionality.
We will need also some way to uniquely identify software and versions at the internet level and being able to manage libraries in central repositories (local or remote ones) and to download libraries and updates on the fly if connected, like Maven do. This in order to avoid duplication of code inside several bundles/applications.
So OSGi/Java 7 + Maven-like repository for application, with local and remote repositories, and versioning is required to achieve all the benefits of manageable set of applications while reducing the size of the container/application sets.
I do hope that it will happen rather soon for mobile and enterprise-level applications.
OSGi and the future Java 7 include such functionality.
We will need also some way to uniquely identify software and versions at the internet level and being able to manage libraries in central repositories (local or remote ones) and to download libraries and updates on the fly if connected, like Maven do. This in order to avoid duplication of code inside several bundles/applications.
So OSGi/Java 7 + Maven-like repository for application, with local and remote repositories, and versioning is required to achieve all the benefits of manageable set of applications while reducing the size of the container/application sets.
I do hope that it will happen rather soon for mobile and enterprise-level applications.
Friday, July 4, 2008
Modularity, Versioning and Container in Java
Modularity, Versioning and Container for multi-applications is expected to come for Java 7. Specifically the JSR 277 and 294 are designed to support these features.
JSR 277 is trying to create a static module system for Java. Its offshoot, JSR 294, is focused on the VM and language support for modularity.
OSGi has been here available since sometime and get some more attentions now as there is a need to support multi-applications running inside a single Java Virtual Machine. There are three independent open source implementations (Equinox, Felix, and Knopflerfish), a specification, reference implementation, and TCK.
JSR 291, which recently passed the Final Approval Ballot, references and extends the OSGi dynamic component system.
In the paper Open Challenges in Ubiquitous and Net-Centric Computing Middleware, I described some of these technologies and how they can be useful for future ubiquitous systems distributed or no.
JSR 277 is trying to create a static module system for Java. Its offshoot, JSR 294, is focused on the VM and language support for modularity.
OSGi has been here available since sometime and get some more attentions now as there is a need to support multi-applications running inside a single Java Virtual Machine. There are three independent open source implementations (Equinox, Felix, and Knopflerfish), a specification, reference implementation, and TCK.
JSR 291, which recently passed the Final Approval Ballot, references and extends the OSGi dynamic component system.
In the paper Open Challenges in Ubiquitous and Net-Centric Computing Middleware, I described some of these technologies and how they can be useful for future ubiquitous systems distributed or no.
Subscribe to:
Posts (Atom)