Java JDK 7 / JRE 7 Final Released : Java Runtime Environment and Development Kit, Five Years in the Making!

Java 7 / JRE 7 (Java Runtime Environment 7) and Java Final Released

Java 7.0 : A Five-Year Wait, Finally Released

Seriously folks, it has been a whopping 5 years since work was started on the successor to Java 6. In that time, Sun Microsystems was purchased by Oracle Corporation, and so much has changed! Think about where the web was 5 years ago and where devices were: you didn't have Android or iPad presence to consider and HTML5 was also nowhere to be found, Google's Chrome Browser was also not around. But, while Java sat in an apparent state of near-dormancy (with regards to major development milestones), the rest of the web changed and JavaScript/HTML5 came into existence and all those devices, browsers, and other technology really took off.

I am one of those developers that kept looking at Java every year or so and contemplating using Java as a software development language / framework, but ultimately choosing each time to NOT go with Java for the simple reason that it looked stagnant and lacking. There were so many missing features that I considered a requirement for any software development language, and the promise of those features coming in Java 7 just continually kept taking more and more time to become reality. I gave up on Java 7 repeatedly with my last major evaluation of the state of Java 7 taking place in mid-2010, where I again passed on it in favor of alternative technologies.

But, yesterday without much fanfare, Oracle finally released the "final" (or should I say "initial") version of Java JRE 7. And, it is not too surprising they didn't make a big deal out of the release, as (from what I observed over the past few years), the only way they could even achieve this 5-year-release milestone was by peeling away features that had been planned for this release (and which are now postponed or will never happen). But, regardless, the JRE 7 / Java 7 release is now available.

What's New in Java 7 / JRE 7 / JDK 7 / Java SE 7

OK, the first thing I can not stand about Java is all this "JRE, SE, EE, JDK, etc." stuff. For god sakes... why so many names? There is the Java Runtime Environment (JRE 7) and the Java Development Kit (JDK 7) and then the confusing "SE" nomenclature (Java Platform, Standard Edition) and "EE" (Java Platform Enterprise Edition), and all the other junk like Javabeans and Enterprise JavaBeans and on and on.

This alone says a lot about what I consider Java: a mess. As much as I am no huge fan of Microsoft's bloated DotNet framework, I consider it a huge improvement (and much simpler to deploy applications based on) over the Java counterpart(s).

Summary of New Features in Java 7

At a very high level, Java 7 includes new features like: some changes to the Java language that should lead to developer productivity improvements; a new Filesystem API and support for asynchronous I/O and even built-in zip-file handling (Java I/O features the new NIO 2, Non-blocking I/O 2); some updates to portions of the framework for multicore performance (like in the fork/join area); improved support for dynamic and script languages; security updates and improvements; and other stuff

Details of New Features in Java 7

I now come back to that whole JRE, JDK, SE, etc. stuff... as I have to tackle the What's New in Java 7 by each of these sub-categories. And, then comes how to even quickly assess the new features in Java 7 when Oracle puts out a page that clearly targets "techno geeks" with terms like RFE, without them even taking time on their web-page to define or explain what an "RFE" is!

So, let me start there, an RFE in the context of Java improvements/bug-fixes/feature-requests is:

Java RFE: Request For Enhancement — i.e., a formal request to Sun (well, Oracle now) to enhance the Java language or the related libraries.

People have been submitting these RFE's for years, and if they are lucky, and enough people really push for something, the RFE may be implemented in a future release of the Java JRE/JDK, etc.  In this case, the Java 7 release includes enhancements that address some rather significant and long-standing RFEs (including a few that kept me from ever commiting to developing any substantial application using Java).

What's New in Java SE 7 and Java JDK 7

Changes to Java SE 7 include changes to the Java language, the definition of the Java Virtual Machine (JVM), or the Java SE API Specification. Changes to JDK 7 includes changes to javac, to HotSpot (and related tools), and to the implementation of the Java SE 7 API. Wow, I already feel like I am going in circles where the JDK 7 changes reference the SE 7 changes and back-n-forth. Ughhhh.

Well, regardless of the absolute mess (in my view) that Java is in, in terms of naming and functional areas of the technology, here are some of the more substantial items in this release (I focus first on items most important to me as a software-developer looking at Java for creating custom software applications):

• Java Programming Language Enhancements : What could be more important to Software Developers? (well, a lot actually,... a great language alone means little without a framework that supports common needs like easy file-I/O, which thankfully is also addressed in Java 7). There are some nice improvements to the programming language worth mentioning here,including:
• Strings in switch Statements : I wish all languages could standardize on supporting this; to me it only makes sense to be able to base a case (switch) statement's execution-branch evaluations on anything, String class or otherwise. Nice!
• Type Inference for Generic Instance Creation : I find this new language feature to be quite nice, and it is representative of what I would expect in most "modern" languages. You can now replace the type arguments required to invoke the constructor of a generic class with an empty set of type parameters (<>) as long as the compiler can infer the type arguments from the context. This pair of angle brackets is informally called the diamond.
• The try-with-resources Statement : I find this new language feature to be quite interesting. There are many times where I can see this making a lot of sense, especially with database connections and the like. The try-with-resources statement is a try statement that declares one or more resources. A resource is an object that must be closed after the program is finished with it. The try-with-resources statement ensures that each resource is closed at the end of the statement. Any object that implements the new java.lang.AutoCloseable interface or the java.io.Closeable interface can be used as a resource. The classes java.io.InputStream, OutputStream, Reader, Writer, java.sql.Connection, Statement, and ResultSet have been retrofitted to implement the AutoCloseable interface and can all be used as resources in a try-with-resources statement.
• Catching Multiple Exception Types and Rethrowing Exceptions with Improved Type Checking : This complements the previous feature nicely, and this should be an improvement over various nested-exception-handling alternatives. A single catch block can now handle more than one type of exception. In addition, the compiler performs more precise analysis of rethrown exceptions than earlier releases of Java SE. This enables you to specify more specific exception types in the throws clause of a method declaration.
• Binary Literals : the integral types (byte, short, int, and long) can also be expressed using the binary number system by adding the prefix "0b" or "0B" to the number. Not a huge change, but nifty.
• Underscores in Numeric Literals : I consider this a "nice to have" more than anything. You can now use any number of underscore characters (_) anywhere between digits in a numerical literal to separate groups of digits in numeric literals.
• Improved Compiler Warnings and Errors When Using Non-Reifiable Formal Parameters with Varargs Methods
• New Java Virtual Machine (JVM) Abilities in Java SE 7: Support for Non-Java Languages (via a new JVM instruction that simplifies the implementation of dynamically typed programming languages on the JVM), Garbage-First Collector (a server-style garbage collector that replaces the Concurrent Mark-Sweep Collector (CMS)), and various Java HotSpot Virtual Machine Performance Enhancements
  
• Enhancements in Java SE 7 JDBC : JDBC 4.1 introduces the ability to use a try-with-resources statement to automatically close resources of type Connection, ResultSet, and Statement and support for RowSet 1.1 (the introduction of the RowSetFactory interface and the RowSetProvider class, which enable you to create all types of row sets supported by your JDBC driver.)
• Enhancements in Java I/O: [this was an area that always prevented me from using Java for any "real" software development work] thankfully, this area got a fair amount of attention with Java I/O features being improved considerably with the new NIO 2, Non-blocking I/O 2. If you need to work with files (I always wondered: "who does not need to?"), this should make Java more usable for what I call "real" applications.
• Swing Enhancements in Java SE 7 : this includes new or improved items including the JLayer Class (a flexible and powerful decorator for Swing components), the Nimbus Look & Feel, support for some mixing of Heavyweight and Lightweight Components, support for Shaped and Translucent Windows (think, modern transparency and non-rectangular shapes), and a tab for Hue-Saturation-Luminance (HSL) Color Selection in JColorChooser Class.
• Networking Enhancements in Java SE 7: a URLClassLoader.close method has been added.
• Java™ SE 7 Release Security Enhancements: a slew of new security related enhancements including a native Elliptic Curve Cryptography (ECC) provider; CertPath Algorithm Disabling (allowing weak cryptographic algorithms to be disabled), and updates to JSSE (SSL/TLS) to support TLS 1.1, TLS 1.2, Connection-sensitive trust management, Endpoint verification, TLS renegotiation, and Server Name Indication (SNI) for JSSE client.
• Concurrency Utilities Enhancements in Java SE 7: The fork/join framework (based on the ForkJoinPool class) is an implementation of the Executor interface designed to efficiently run a large number of tasks using a pool of worker threads.
• Client JRE Capabilities (RIA - Rich Internet Applications in particular) have been further improved to create what I call "modern" looking applications.
• Java 2D Enhancements in Java SE 7: a new XRender-based Java 2D rendering pipeline is supported for modern X11-based desktops, offering improved graphics performance; Support for OpenType/CFF Fonts, and Support for Linux Fonts(where libfontconfig is used to select fonts to use for the logical fonts for "unrecognized" Linux platforms)
• Plus other enhancements to: Java XML Technology (JAXP, JAXB, JAX-WS); Multithreaded Custom Class Loaders in Java SE 7 (potential deadlocks were eliminated for multithreaded, non-hierarchically delegating custom class loaders),

Some Other RFE's addressed in Java 7

The following is a list of some of the RFE's that were addressed in Java 7 that I considered noteworthy as I dug through the rather lengthy list of RFEs discussed in the release notes for Java 7 (there are quite a few more, but these are things I had interest in):

• (Tools) A succinct and concise error message is printed, as appropriate, when an error occurs during the Java launcher initialization.
• (Tools) The HtmlConverter tool is no longer part of the JDK 7 distribution
• (Tools) The javadoc tool has been updated to use style markup classes that can control the styles of the generated pages.
• (HotSpot) The default out-of-the-box heap size and shape parameters for the concurrent mark sweep collector (CMS) have been modified. The new settings take advantage of faster platforms [yeah, I'd say so in five years!] that have introduced since JDK 6 was released.
• (HotSpot) The GarbageFirst (G1) garbage collector is experimental in this release.
• (Plugin) 64-bit toolkit is now supported on 64-bit Windows platforms.
• (Plugin) Google Chrome is now supported by the DT Plugin (DT being deployment toolkit I believe).
• (API: AWT - Abstract Window Toolkit) All java.awt.Window objects (not frames or dialogs) are regular top-level windows on X11.
• (API: AWT) The mechanism used to detect whether the window manager supports a system tray has been changed (now uses the System Tray Protocol Specification)
• (API: AWT) Limited mixing of heavyweight (e.g. AWT) and lightweight (e.g. Swing) components is now officially supported.

More on What's New in Java7 / JRE7 / JDK7 / Java SE7

I hope I have given you a feel for what to expect with regards to new features in Java 7, especially features that may be interesting to you as a software developer. I MAY take Java seriously as a potential development language now, but... I need to dive into things like the file-I/O in more detail and see how it compares to what I am used to with Embarcadero Delphi (VCL Framework) or Microsoft DotNet Frameworks and development environments and languages.

Also, there were a LOT of big features that were highly anticipated (by me, and others) originally slated for Java 7 that did not make it into this release. Things like unified and robust date / datetime / time support. To me, I can hardly take any language/framework seriously if it does not provide native support for this type of thing. Sure, I can add on the the support I need (perhaps) with something like Joda / Jodatime or whatever, but please... why is something so basic (as a business software requirement) not included in the basics of the framework, language, types, etc? I find that really annoying, and another reason I avoid Java (or have avoided; time will tell if my avoidance is permanent).

 I really WANT to use Java for some things and want to be able to use Java for certain things — in particular I have some projects I wanted to implement using NetBeans platform components, which would sure imply Java as my primary development language to go with it ideally. Well, we shall see. If you want more information see this Java7 link to Oracle's page of Java 7 New Features and Release Notes and such.

Get ready to dive into all sorts of detail and read those lovely "RFE" entries!

VMware ESXi 5.0 New Features and vSphere 5.0 New Features

UPDATE: see my newer blog entry for latest (Sept-2012) VMware ESXi 5.1 info.

I recently posted a blog about the expected VMware ESXi 5.0 New Features, and since that posting just a couple months ago, VMware has released to the public the details of new features in VMware ESXi 5.0 and vSphere 5.0; so, this is a followup blog to cover the "official" new features in ESXi 5.x ...

New Features in VMware ESXi 5.0

Before getting into the new features in vSphere 5 / ESXi 5, I want to start with some helpful terminology, in case you are not familiar, as this will be mentioned a few times in the coming paragraphs as it relates to new significant features in the VMware products: ".VIB" files. You may have seen these VIBs before when you were upgrading VMware (e.g., as described in my how-to upgrade VMware ESXi 4.0 to 4.1 blog).

A .vib file is an ESXi / vSphere (or VMware) Installation Bundle (VIB file) that is essentially just a Debian (Linux) Package from what I have been able to deduce; and, not surprisingly, these .vib files may be referred to as "Software Package" files too.  These .vib files come into play as VMware (and partners / providers) package their solutions, drivers, CIM providers, and applications which are designed to extend the ESXi platform in some way.

Those .vib files are going to play an important role for the new Image Builder and Auto Deploy features, as any given ESXi Image is composed of VIB files (software packages) for 1) the core hypervisor, 2) Drivers, 3) CIM providers, and 4) other plug-in components. And, .vib files can include information about relations with other .vib files (e.g., ones they depend on and/or may conflict with).

ESXi 5.0 : Image Builder (NEW)

Image Builder is a new new set of command line utilities that allow administrators to create custom ESXi images that include 3rd party components required for specialized hardware (like drivers and CIM — Common Information Model &mdash providers). These utilities are used to create images suitable for different types of deployment, such as ISO-based installation, PXE-based installation (Preboot Execution Environment), and Auto Deploy (a new mechanism for provisioning ESXi hosts under vSphere 5.0)
Image Builder is designed as a Power Shell snap-in component and bundled with PowerCLI.

Image Builder is meant to help overcome limitations that exist where the Standard ESXi image (ISO), with its base providers and base drivers, does not have all the drivers or CIM providers for your specific hardware and/or does not otherwise include the vendor-specific plug-in components you require. Put another way, Image Builder will allow you to create and manager image profiles and build ESXi customized boot images (e.g., installable .ISO images or bundles ready for PXE installation). These images can then be placed in a "Depot" (a repository containing your image profiles and relevant VIBs), and these "Depots" can exist as a web-server-type-depot or a ZIP-file-encapsulated-depot .

Ultimately, ImageBuilder will allow you to then clone and modify an existing image profile, selecting the various VIBs you want to incorporate (be it drivers, ESXi VIB files, and/or OEM VIBs), and generate an ISO image (for a CDROM/DVDROM) and/or a PXE-bootable image. Whew! Got that? Well, this should at least give you an idea of what the new feature is for... and how it also goes along with the next new feature...

ESXi 5.0 / vSphere 5 : Auto Deploy (NEW)

Since I mentioned it in the prior paragraph, here is a bit more discussion about the new "Auto Deploy" construct. Quoted from the VMware "What's new in vSphere 5" PDF, "Auto Deploy is a new deployment and patching model for new vSphere hosts running the ESXi hypervisor. Deploy more vSphere hosts in minutes and update them more efficiently than ever before."

So what exactly does that mean?

Auto-Deploy is based on PXE-Boot (i.e., the ability to boot an ESXi host over the network), and works with Image Builder, vCenter Server, and Host Profiles.  It works like this: PXE boots the server, the ESXi image profile is loaded into host-memory via the Auto-Deploy Server, configuration information is applied (using Answer File / Host Profile  —  answer files being a new 5.0 construct), and the host is placed/connected in vCenter.

This has substantial advantages in that it requires no boot disk (on each connected host), and theoretically you can use it to quickly deploy a large number of ESXi hosts over the network and share a standard ESXi image across many hosts — the ESXi host-image has been effectively "de-coupled" from the physical server; secondarily this implies that you could recover a (failed) host without recovering the physical hardware and/or restoring from a backup [NOTE: an assumption here is that you have another server available with matching hardware].

This new (Auto Deploy) approach has a lot to offer!  This should allow you to setup a single boot-image that can be shared across hosts; and, with every reboot each host is starting up with a consistent image (keeping you servers all in-sync with regards to their ESXi setup).  This will likely replace a lot of custom scripting and other home-spun solutions currently in existence.  I can see this being a HUGE advantage when dealing with massive server farms.

With all "state information" being stored off the host and in vCenter Server (rules store; host configs saved in host profiles; custom host-settings saved in "answer files"), one has to wonder (well, I certainly wonder), whether this is putting "all your eggs in one basked" a bit? Also, this clearly implies one serious Enterprise-grade setup for your network and hardware (can you say, redundancy and fault-tolerance!?).  All steps of the Auto-Deploy (to me at least) certainly will require a rock-solid infrastructure: from 1) PXE Boot, to 2) the boot contacting the auto-deploy server, to 3) the auto-deploy rules-engine determining what image profile, host-profile (and cluster) is being dealt with, to 4) pushing the appropriate image to the host requesting it and applying the proper host profile, to 5) placing the host into a cluster... that all sounds a bit intensive to me.

Well, that is a summary of what this new "Auto Deploy" is all about... hope it at least gets your interest.  I have no way to really test this out much in my environment, as I do not have piles of servers sitting around to play with, etc.

ESXi 5.0 : Firewall (NEW)

Quoted from the VMware "What's new in ESXi 5" web page: "The ESXi 5.0 management interface is protected by a service-oriented and stateless firewall, which you can configure using the vSphere Client or at the command line with esxcli interfaces. A new firewall engine eliminates the use of iptables and rule sets define port rules for each service. For remote hosts, you can specify the IP addresses or range of IP addresses that are allowed to access each service."

I guess this is something I should get excited about. I did always find it (a bit) concerning that ESXi had no built-in firewalling in previous versions of the product. Has it ever caused me an issue? Well, no... but, I also have another layer of hardware firewalls around my servers that has (so far) done the job just fine. But, more security is generally a good thing, and presuming it does not impact performance (which, it seems is very unlikely), I see no reason why I would not use it.

New (Version 8) Virtual-Machine format with 3D (Windows Aero) and USB 3.0 Support : Great News for us Software Developer Types!

Since I use VMware ESXi for a lot of software-development-related tasks (including testing software under various operation systems for consistency, etc), I was thrilled to see support for 3D graphics (though, non-hardware-accelerated support) for Windows Aero (this is going to be quite handy for my Windows-7 x32/x64 testing).

And, I am definitely looking forward to the USB 3.0 device support. There are some limitations with this support, but I still hope to take advantage of any increased throughput to my external USB3 devices.  Again, quoted from VMware's "What's new in ESXi 5.0" web page: "ESXi 5.0 features support for USB 3.0 devices in virtual machines with Linux guest operating systems. USB 3.0 devices attached to the client computer running the vSphere Web Client or the vSphere Client can be connected to a virtual machine and accessed within it. USB 3.0 devices connected to the ESXi host are not supported at this time."

So, the wording of that paragraph could certainly be better.  What it sounds like is that VMware was unable to implement support for USB 3.0 devices under Microsoft Windows based Guest Virtual Machines at this time.  And, although the Linux-guest VMs can connect to a USB 3 device, that "connection" is essentially made over just a "pipe" of sorts that is passing data flowing to a local USB 3 connection (local to a machine running the vSphere client) over the network to our ESXi-hosted-VM?  So, to say that another way... it looks like we are going to be able to connect USB 3 devices, to Linux-guest-VMs only, and even then we will be passing that USB3 traffic over our network?  Wow, that surely diminishes my initial excitement with this feature, but at least I can still "attach" a USB3 device to an ESXi-hosted VM (not quite the same as plugging that device into my server, directly, though!)

I would expect this USB 3.0 support to improve with ESXi 5.1 or such.  I can understand why this approach would have been taken, as it would be much simpler to implement.  The fact is, if a local machine (running vSphere client) has access to a USB 3.0 device, we already have the two things we need: a network connection to ESXi, and a computer and OS that supports USB 3.0 devices and can "talk" to them... so, what easier way to implement some type of support in ESXi (VMs) than to pipe data across the network to those VMs.  But, if that was the reasoning, I do not fully "get" why only Linux VMs would support this.  Maybe I am just confused.  I need to do some testing and see what I run into.

Other new virtual-hardware features:

• 32-way virtual SMP
• 1TB virtual machine RAM
• UEFI virtual BIOS. Virtual machines running on ESXi 5.0 can boot from and use the Unified Extended Firmware Interface (UEFI).
• Smart card reader support for virtual machines (implemented *somewhat* like USB3 support in that this refers to smart card readers attached to the client computer running the vSphere Web Client or the vSphere Client); those smart cards can be connected to one or more virtual machines running under ESXi. And, the virtual machine remote console (in the vSphere client products) support connecting smart card readers to
  multiple VMs, making them useful for smart card authentication to VMs.
• Apple Mac OS X Server guest OS support — but, before you get TOO excited, this new vSphere 5.0 support for the Apple Mac OS X Server 10.6 (“Snow Leopard”) as a guest operating system is restricted to running only on certain Apple Xserve model hardware. I guess if you are "an Apple shop", this will be a neat feature.  Otherwise, it is a bit lack-luster from where I sit... I would have very much liked to run OSX 10.6 or 10.7 and such inside a hosted VM so I could use it for testing web-sites under Safari and other things.  Oh well.
  

Other New and Enhanced ESXi / vSphere Features

In no particular order...

• Swap to SSD. (I am very interested in this, as I hope to make use of my Intel SSDs that have done so well already on my desktops and existing ESXi 4.1 server). vSphere 5.0 provides new SSD handling and optimization whereby the VMkernel automatically recognizes and tags SSD devices (local to ESXi or available on the network), and can apparently use this information to allow the ESXi swap to extend to those SSD devices and enable memory-over-commitment while minimizing the performance impact).
  
• Support for SNMP v.2 with full monitoring for all hardware on the host.
• Secure Syslog (system message logging) enhancements.
• Enhanced Unified CLI Framework, including the ability to use the esxcli framework both remotely as part of vSphere CLI and locally on the ESXi Shell (formerly Tech Support Mode).
• Profile-Driven Storage, Storage I/O control, Network I/O Control, and Distributed Switch for additional Enterprise-Level performance and control features.
• And, oh yeah... you may have noticed the mention (throughout this blog) of the vSphere Web Client... that too is new, and as the name implies, it is a browser-based implementation of the vSphere Client... and, it is (at this time) a limited subset of what the full vSphere Windows UI / Client contains.  I expect this will eventually evolve into the full-fledged vSphere client over time, thus making the management client available on all clients (and OS's), via modern web browsers.

The fact is, there is a LOT of new features in this latest release of ESXi 5.x and vSphere 5.x that are worth checking out.  If you need more details, I suggest going to VMware's website and checking out all these products, whitepapers, announcements, and such.

How-to: Shutdown Windows 2008 without Logging In First

Windows 2008 / 2008r2 Server
Enable Shutdown Option on Logon Screen

Display the Shutdown / Restart Option on Login (Log On) Screen

Since I tend to run a lot of software development virtual machines, I quite often want to start up, and shut-down, various instances of operating systems with as little additional effort (and wasted time) as possible. Windows 2008 (and 2008r2) is one of my Microsoft development operating-system platforms that I interact with, especially for hosting SQL-Server 2008 / 2008r2 on. And, since SQL-Server 2008 will gracefully startup and shutdown automatically as the underlying Windows 2008 operating system starts and stops, I have no "need" to truly "Log In" (logon) to the OS Desktop via CTRL-ALT-DEL logon process for most occasions.

As such, I always want the option of shutting down the Windows 2008 server without logging in; but, it turns out that thanks to a default security policy, the shutdown option is not available on the logon screen unless we make changes to the Local Security Policy to allow the shutdown button to show on the the login page.

Procedure to Enable Shutdown-on-Logon Screen

This is what we WANT to have available after we press the CTRL-ALT-DEL key combination (or, CTRL-ALT-INS when running within a VMware virtual machine):

Now, to get to where the options above are present at log on, we must take the following steps (click on image for larger views)...


Run this : gpedit.msc -- this will launch the Local Group Policy Editor (the .MSC file-extension tells you that we are working with a Microsoft Management Console Snap-in Control File)

Now, once the Local Group Policy Editor is displayed, Navigate to the proper sub-tree, which is: Computer Configuration, Windows Settings, Security Settings, Local Policies, Security Options, Shutdown.  On the right-side/pane of the screen, scroll down to the Policy labeled "Shutdown: Allow system to be shut down without having to log on" and change the value of this Security Setting column to be "Enabled".

Once you have saved this, the next time you reboot your server, you will be presented with the shutdown options on the Windows 2008 log on screen (as shown in the image I inserted at the beginning of this section) that will allow you to perform a shut down or restart without the need to login to the desktop first.  This is a HUGE time-saver for me, and I hope it saves you some time also.

Enable Copy / Paste in ESXi 4.1 Virtual Machine : VMware vSphere Client 4.1

Enable Copy / Paste in ESXi 4.1 / vSphere 4.1 Guests - VMware Virtual Machines

vSphere 4.1 Copy/Paste options : Change of Default Behavior

This is one of those changes that was implemented "for security reasons", where an existing behavior and capability (with ESXi 4.0 / vSphere 4.0 and earlier) suddenly seems to no longer work for you: you simply want to Copy/Paste to and/or from your Guest Virtual Machine like you had been doing prior to your ESXi 4.1 upgrade, but suddenly that "feature" is no longer working.

After some digging, you will find that VMware posted a KB about this stating: "Starting with vSphere 4.1, the Copy and Paste options are, by default, disabled for security reasons.". OK, lovely... so, let us go about "fixing" it (i.e., restoring our copy/paste option for a particular virtual machine and/or turning it on by default for all our VMs).

SIDE NOTE: I wrote a blog about How to Upgrade VMware ESXi 4.0 to 4.1 recently, if you have yet to do so and want to get some experience before upgrading to ESXi 5.0 / vSphere 5.0.

VMware ESXi / vSphere 4.1 Enable Guest Copy/Paste Operations

I included a quick visual (screenshot with markups) showing you how this looks in the vSphere 4.1 client software application.

This screen shows how you modify the settings for a single virtual machine. You can see that I have just chosen to "Edit Settings..." on a (stopped) virtual machine, where I have then gone to the "Options" tab, selected "General", and clicked the "Configuration Parameters..." button, whereby the form (that I marked up above) is shown.  To add the two entries we need (as pictured: click picture to zoom in), simply click the "Add Row" button (twice in total as we do this), and add these entries (name : value pairs):

• isolation.tools.copy.disable : false
• isolation.tools.paste.disable : false

Then click OK to exit this screen, and OK again to exit the edit-settings screen.  Power up your virtual machine, open a console window to it, and once your guest operating system is up and running, you should find that you can now copy and paste between your host and guest(s).

VMware ESXi / vSphere 4.1 Enable Guest Copy/Paste DEFAULT (for all VMs)

What do you do if you have a LOT of virtual machines to make this change for? I figure the break-even threshold for going about the "bulk enable" method as I am about to describe is probably more virtual-machines than I had (less than 10), but there is a solution for enabling copy/paste by default. NOTE: this requires gaining access to the the ESXi Server Console as "root" (if you do not know how to do this, see that link I provided above for upgrading ESXi 4.0 to ESXi 4.1 -- it will walk you through this step).

Once you have access to the server console, you need to open the /etc/vmware/config file using a text editor and add these entries to the file (which should look very familiar after the discussion above):

• isolation.tools.copy.disable="FALSE"
• isolation.tools.paste.disable="FALSE"

Save and close the file. You will see the effect of the newly enabled Copy / Paste options only after you restart or resume your virtual machine(s).


Note: According to VMware, these options (both methods described, from what I gather) do not persist after an upgrade. If you upgrade to a newer version after enabling these options, the changes are lost and you may have to re-enable them. That may be a PITA, but at least there is a way to fix the copy/paste, and that is all I care about really :)

How to set default form font Delphi 2010

Delphi 2010: How to set Default Font for New Forms

Delphi 2010: Great IDE, but a DefaultFont fix needed!

I use Embarcadero Delphi 2010 (formerly Borland Delphi and/or CodeGear Delphi) for developing various Microsoft Windows®-based applications, and I generally love the IDE (Integrated Development Environment) for this RAD (Rapid Application Development) tool and object-oriented-development language and visual-component-library platform. But, once in a while I find some frustrations that just have to be dealt with the old-fashioned way: a registry-hack (or series of them)!

The latest need for a "fix" came when I moved from Delphi 2010 on Windows XP to using Delphi 2010 on Windows 7.  The old Delphi form-designer default form-font I was accustom too while under XP was Tahoma, which was just fine... but, according to Microsoft:

Users interact with text more than with any other element in Microsoft® Windows®. Segoe UI (pronounced "SEE-go") is the Windows system font. The standard font size has been increased to 9 point.

So, I get Delphi 2010 installed on Windows 7 x64 (64-bit environment) and go about a quick test of creating a new VCL Forms Application — and, for some reason I just rather expected the Default Font for Delphi 2010 to be Segoe UI 9-point... well, that is just not the case.  So, how could I make Segoe UI the default font for Delphi?  It should have been a simple single-entry into the registry (like it used to be in earlier Delphi versions), but no, that no longer works. Instead, the following sequence of registry changes must be implemented...

Registry Edits to Change Delphi 2010 Default Form Font

We start by navigating to the proper Windows Registry location (using REGEDIT). See the picture (click for larger version if needed)...

I began by adding a new key under HKEY_CURRENT_USER\Software\Codegear\BDS\7.0 called FormDesign (notice: no space in name); this is not to be confused with the existing key called "Form Design".

Then, in the existing "Form Design" key (the one with a space in it), edit the value for "Embedded Designer" and set it to False. NOTE: the default font fix we are implementing here will not work unless you turn the embedded-designer off — apparently this is thanks to a bug in Delphi 2010.

Now, within that NEW FormDesign key (the one without a space!), add a key/value(string type) pair as show in the next image. This key has the name DefaultFont and an associated string value that contains your desired default font-name, font-size, and even style (e.g., you could append the word bold to this) — in this example, I wanted Segoe UI 9-point (to fit with Microsoft's Windows-7 standard font guidelines). Notice how if the font-name you choose to use has a *space* in it, you MUST enclose the font-name in double-quotes as shown or the Delphi UI will not implement your default font. There is no space anywhere else in the line I show (i.e., no space after separating comma, etc.)

In the next image, I have shown a screen print of the Delphi 2010 Object Explorer showing the Font property values for a brand new form. you can see that my newly specified default Font-Name and Font-Size are taking effect in the Delphi 2010 IDE, albeit with the caveat that the form-designer is not currently "embedded" (since we had to turn off the embedded-designer to get this to work. You can toggle the embedded-designer back on (registry value = True) when you want to edit forms in the usual non-free-floating-form-editor layout. And, once you have your new form(s) created/saved, you can certainly set the embedded form designer to its default for good if you want (don't worry -- your new default font values are persisted when you save a form and will not change).

Updating Existing Forms to new Default Form Font

To quickly update any existing forms, and the controls / components contained on them, I simply did this:

1. Created a new empty form (with my new Segoe UI 9-point, from new defaults)
2. Opened up an existing form that needed its look updated; select-all; copy...
3. Back on my new empty form, I pasted all the copied items.  Now, assuming you have a font-inheritance-hierarchy that supports what is going on (i.e., ParentFont property = True), your pasted controls should reflect that new look.
4. Make adjustments for new visual size-differences, etc. in my layout.
5. Close the old (original) form; name the new form to what the old was and save the new unit with the name of the old.  (note: I have everything under version-control; I suggest having this or some other means for rolling-back if you experience issues).

Enjoy!