After 4 1/2 years it was time to send my old laptop into retirement. A replacement laptop with a 512 Gig SSD Samsung PM830 did the trick. Old laptop was freshly defragmented XP 32 bit 2 gig ram dual core 2.2 GHz cpu. New had Win 7 64 bit, 16 gig, 512 SSD quad core i7 2.5 GHz.
Building my system both with a 32 bit JDK with ProGuard obfuscating turned on "Clean and Build all":
OLD system: 4' 25 sec
NEW system: 1' 29 sec
Launching NetBeans (6.5) with around 50 modules:
OLD system: 25 sec
NEW system: 8 sec
In general a 3x increase in speed ! I strongly believe the disk I/O is the major consumption of time here. CPU and Memory is only contributing minor.
Saturday, May 12, 2012
Wednesday, December 7, 2011
Multiline ToolTips
Funny, never thought about it, but when using a ToolTip with NbBundle.getMessage and a property in the Bundle.properties it is of course possible to make a multipline ToolTip by using the <html> HTML tag. An two line example would be:
Have this as ONE line in the Bundle.properties file.
LBL_DeltaX_ToolTip=<html>Change in x direction in mm.<\br>Some other second line text</html>
Have this as ONE line in the Bundle.properties file.
Saturday, December 3, 2011
Access currentVersion
The currentVersion property is used to for example show the version number of your RCP in the Title line. Now it can be set via branding
${basedir}/branding/core/core.jar/org/netbeans/core/startup/Bundle.properties Nothing new here. The trick is if this holds information you would like to retrieve at runtime.
Naively one could try NbBundle.getMessage(Main.class, "currentVersion"); which will fail.
I have found a way around which may not be the most obvious path - but at least a solution which might help others. I had to work around it by copying the content of that property to a Bundle.properties file which is within my access space. I do this via Ant when building the app each time. Example:
In the main build.xml add a target
The target above will create a property in the Bundle.properties file in the package /com/mycode/xyz of moduleA You could here instead of using ${app.version} use ant command to read the currentVersion property if already set. If it is in your control you can of course set the currentVersion automatically as well like adding the following into the same ant target. ${build.number} and $(app.comment} are my own properties - but you get the point.
If you do this first you can set the "fullVersion" (or whatever you would like to call it) property to the moduleA/com/mycode/xyz package and a method like
public String getFullSoftwareVersion() {
// This value is stored in the Bundle.properties of this package
return NbBundle.getMessage(MyClassXyz.class, "fullVersion");
}
As this is within your code you can now read the value.
${basedir}/branding/core/core.jar/org/netbeans/core/startup/Bundle.properties Nothing new here. The trick is if this holds information you would like to retrieve at runtime.
Naively one could try NbBundle.getMessage(Main.class, "currentVersion"); which will fail.
I have found a way around which may not be the most obvious path - but at least a solution which might help others. I had to work around it by copying the content of that property to a Bundle.properties file which is within my access space. I do this via Ant when building the app each time. Example:
In the main build.xml add a target
<target name="build-brand" depends="-init">
<propertyfile
file="${basedir}/../moduleA/com/mycode/xyz/Bundle.properties"
comment="Updated by build script for full version info">
<entry key="fullVersion" value="${app.version}" />
</propertyfile>
</target>
The target above will create a property in the Bundle.properties file in the package /com/mycode/xyz of moduleA You could here instead of using ${app.version} use ant command to read the currentVersion property if already set. If it is in your control you can of course set the currentVersion automatically as well like adding the following into the same ant target. ${build.number} and $(app.comment} are my own properties - but you get the point.
<propertyfile
file="${basedir}/branding/core/core.jar/org/netbeans/core/startup/Bundle.properties"
comment="Updated by build script">
<entry key="key="currentVersion" " value="${app.title} ${app.version}.${build.number} ${app.comment}" />
</propertyfile>
If you do this first you can set the "fullVersion" (or whatever you would like to call it) property to the moduleA/com/mycode/xyz package and a method like
public String getFullSoftwareVersion() {
// This value is stored in the Bundle.properties of this package
return NbBundle.getMessage(MyClassXyz.class, "fullVersion");
}
As this is within your code you can now read the value.
Labels:
currentVersion,
NetBeans
Saturday, January 15, 2011
VisualLibray Z-order problem for ComponentWidget
For too long I had a problem with the Z-ordering of ComponentWidget's in VisualLibary.
As a reference it was fixed in NetBeans 6.8 (see http://netbeans.org/bugzilla/show_bug.cgi?id=169373 and the fix source in http://hg.netbeans.org/main-golden/rev/da7547f37f44).
As I am still in NetBeans 6.5 the solution was simply the use the 6.8 jar of the org-netbeans-api-visual.jar and replace the one in your Nb 6.5 install under platform9/modules.
Note that you CANNOT use the version from 6.9 or later due to some major refactoring of modules (like the Lookup got its own module).
This now works perfect.
As a reference it was fixed in NetBeans 6.8 (see http://netbeans.org/bugzilla/show_bug.cgi?id=169373 and the fix source in http://hg.netbeans.org/main-golden/rev/da7547f37f44).
As I am still in NetBeans 6.5 the solution was simply the use the 6.8 jar of the org-netbeans-api-visual.jar and replace the one in your Nb 6.5 install under platform9/modules.
Note that you CANNOT use the version from 6.9 or later due to some major refactoring of modules (like the Lookup got its own module).
This now works perfect.
Labels:
NetBeans,
Visual Library
Saturday, October 23, 2010
Java to be depricated on Mac OS ?
Normally I do not really get excited about all the noise Google and Apple are making with indirect threats to each other . I love the products both companies are making available to us plain mortals and we choose what we like best and focus on making great application which make those companies grow. But the latest comment from Apple about possible depricate Java on future releases of Mac OS is just plain evil and really irritates me.
http://www.theregister.co.uk/2010/10/21/apple_threatens_to_kill_java_on_the_mac/
I hope this backfires. Luckily history has proven that such protectonism of your own little empire typically cannot be supported in the long run.
No Mac for me anymore.
http://www.theregister.co.uk/2010/10/21/apple_threatens_to_kill_java_on_the_mac/
I hope this backfires. Luckily history has proven that such protectonism of your own little empire typically cannot be supported in the long run.
No Mac for me anymore.
Labels:
Mac OS X
Monday, May 3, 2010
Testing NBM's for update center locally
When creating NBM's to be deployed for an update center NetBean's nicely create a list of NBM's and the corresponding update.xml file.
Now, when you would like to test those NBM's I often upload to a dev-area on my webserver to test the update. A faster way to check the consistency of the generated files is directly to enter a File URL in the the Settings for the Update Center.
An example of the syntax to use to read those update from a local Windows disk:
Now, when you would like to test those NBM's I often upload to a dev-area on my webserver to test the update. A faster way to check the consistency of the generated files is directly to enter a File URL in the the Settings for the Update Center.
An example of the syntax to use to read those update from a local Windows disk:
file:/C:/svn/trunk/myapp/build/updates/update.xml
Labels:
NetBeans,
Update Center
Friday, February 26, 2010
As I was trying to launch a NetBeans RCP app from an external drive with a specific JRE also deployed on that external drive, I had a little trouble to also have the user directory located there.
My mistake was to have the user directory specified in the same directory as the RCP app.
Example: Assume you create a ZIP of your app called "MyApp". It will be in a folder called "MyApp" (The folder is containing "bin", "etc", and so on). To make sure it uises a given tested version of the JRE assume you also have a copy of the JRE in that deployment dir.
NOT WORKING :
The code above will create the userdir but than just exit. I have no explanation for this behavior. What solved the problem is to make sure the user directory is not under the deployment directory
WORKING:
Which put the user directory parallel to the deployment directory.
My mistake was to have the user directory specified in the same directory as the RCP app.
Example: Assume you create a ZIP of your app called "MyApp". It will be in a folder called "MyApp" (The folder is containing "bin", "etc", and so on). To make sure it uises a given tested version of the JRE assume you also have a copy of the JRE in that deployment dir.
NOT WORKING :
set MYAPP=%~dp0
"%MYAPP%\bin\myapp.exe" --jdkhome "%MYAPP%\jre6" --userdir "%MYAPP%\myuserdir"
The code above will create the userdir but than just exit. I have no explanation for this behavior. What solved the problem is to make sure the user directory is not under the deployment directory
WORKING:
set MYAPP=%~dp0
"%MYAPP%\bin\myapp.exe" --jdkhome "%MYAPP%\jre6" --userdir "%MYAPP%\..\myuserdir"
Which put the user directory parallel to the deployment directory.
Subscribe to:
Posts (Atom)
