Archive for the ‘Java’ Category

Published JavaDocSuppressor or jadosu v1.0 to github

Saturday, August 25th, 2012

So every so many time I come across some Java code that’s littered with useless JavaDoc comments that do nothing more than obfuscate what the code actually does. So when I found myself looking for the same set of regular expressions yet again I thought it wise to finally automate it.
The binary downloads as well as the Java sources can be found on github. The whole is available under the Apache License 2.0.

Rather than modifying the original sources, the modified sources are stored at a designated  directory path which will be created. Unmodified sources can be optionally included as well by provided the ‘-i’ argument, effectively resulting in a full copy of the source path with modified sources.

Grab it here

Sending email to your SSL/TLS enabled smtp with Spring from WAS/Glassfish

Monday, February 28th, 2011

So what I needed to accomplish:

  • send automated emails from a webapp using Spring 3.0
  • running on a Glassfish / WAS  instance
  • to an SSL/TLS secured SMTP (smtps) service running on a different host

Import the certificate

First of all, we need our jvm to trust the certificate of the remote host that offers the smtps service which in my case is available on port 465 (which is common).

To do that, first of all read Andreas Sterbenz’ old Sun blog post regarding the InstallCert tool he wrote.

Download InstallCert.java to some directory, move to that dir, and run
javac InstallCert.java

Next, run
java InstallCert

from the same dir to get usage instructions.

I went for the version
java InstallCert your.host.com:your_port

After selecting the certificate you want to add to the trusted keystore by pressing the associated number you’ll end up with a file called jssecacerts in your working directory.

Also note the last line of the generated output, which should be something along the lines of:
Added certificate to keystore ‘jssecacerts’ using alias ‘your.host.com-1′

You’ll need that alias for the next step.

Export the certificate from the keystore file ‘jssecacerts’

To do this we’ll use keytool, note the alias name which needs to be equal to the one mentioned in the last step:

keytool -export -alias your.host.com-1 -keystore jssecacerts -file my_actual_cert.cer -storepass changeit

We now have a file representing the actual certificate we need to trust in order for our application to be able to set up a secured connection with your.host.com

Importing the certificate

Before we get to use keytool again, make sure you have proper permissions to modify your JRE installation and go to
<jre_root>/lib/security

Eg. for the Sun (Oracle) JDK on Debian/Ubuntu <JRE_ROOT> could be
/usr/lib/jvm/java-6-sun/jre
You should see a file cacerts in this directory. Next run:
keytool -import -alias your.host.com-1 -file my_actual_cert.cer -keystore cacerts -storepass changeit

This will effectively add the certificate you just exported to the trusted certificates.

Making Glassfish trust our certificates

To do this, you need to point to the trustStore you just updated (cacerts) in the properties associated to the Glassfish JVM.
First of all copy the cacerts keystore file you just updated to <your_glassfish_domain>/config/my-cacerts.jks

Next login to the Glassfish Admin Console, and proceed to
Common Tasks -> Configuration -> JVM Settings -> JVM Options

Change the property
-Djavax.net.ssl.trustStore=${com.sun.aas.instanceRoot}/config/cacerts.jks

to
-Djavax.net.ssl.trustStore=${com.sun.aas.instanceRoot}/config/my-cacerts.jks
Save your changes and restart glassfish.

Making WebSphere Application Server trust our certificate

is documented here (among other places no doubt); basically the same steps.

Sending mail

Check out one of many samples available online showing how to send email using Spring facilities. This is a quick and dirty example without injection.

<bean id="mailSender" p:port="your_port" p:host="your.host.com" p:username="your_authenticating_user" p:password="your_pwd" p:protocol="smtps">
    <property name="javaMailProperties">
      <props>
        <prop key="mail.smtps.auth">true</prop>
        <prop key="mail.smtp.starttls.enable">true</prop>
     </props>
    </property>
</bean>

Afterwards you can just inject the mailSender and use it as desired.

Note that you can easily inject a JNDI mail session, which I didn’t do because there’s no real advantage to warrant having to ensure the proper JNDI resource(s) exist on different servers in this case.

Happy sending! :-)

SwingWorker publish() and process()

Sunday, December 19th, 2010

I just converted a bunch of legacy code that made use of the add-on SwingWorker version from the Java 5 days to use SE 6′s SwingWorker. Definitely an improvement however I wasn’t getting the updates I expected using the publish() process() mechanism as all data published during the background task was being processed in one go only after the actual background task had finished.

The cause? Starting the SwingWorker operation with run() instead of (the correct) execute().

Is the Java Store dead ?

Friday, June 4th, 2010

I’ve been waiting since Devoxx for the Java Store to become available in Belgium.Seemingly zero changes since then :-(

Although it might not be the most original idea, it does sound like a natural fit for the java platform on the desktop.

Anyone knows if Oracle killed this off or if it died when James Gosling left Oracle ?

I for one am still rooting for this to actually happen. Yes I’m a dreamer.

Compiling Spring 3 from SVN on Linux

Wednesday, November 11th, 2009

Mostly so I don’t forget myself next time :-)

Don’t forget to checkout only the wanted HEAD revision from svn:

svn co -r HEAD https://src.springframework.org/svn/spring-framework/trunk spring-framework

If you have ant as part of your distro (as is the case in gentoo), download a binary ant distribution and run <your_new_ant_path>/bin/ant instead of the ‘default’ ant to prevent any classpath issues.

Make sure you do

export ANT_OPTS=”-XX:PermSize=128m -XX:MaxPermSize=128m”

If necessary add -Xmx512m or more too.

Enter build-spring-framework and run

<your_new_ant_path>/bin/ant

to build Spring. In order for Eclipse to be able to find all required jar’s, you’re probably best running the resolve ant target in most of the subprojects.

Open import the projects to an Eclipse workspace, set the IVY_CACHE classpath var in Eclipse prefs to spring-framework/ivy-cache

I had a few errors in tests for the oxm bundle failing, but since I don’t really need them anyways I just removed the src/test source dirs from the oxm project in Eclipse :-)

It’s 2 AM so yea, the above is probably pretty messy :)

64bit java plugin out in the wild aka Sun Java 6u12 released!

Monday, February 2nd, 2009

Get it hot! :-) As I’ll probably be waiting for this release to hit the/some Gentoo/Ubuntu repo, I have to say I’m surprised at the seemingly short interval between the last update releases. Seems 11 was only last week somehow.

As my previous Athlon64 and current Intel i7 Core are both 64bit, I do have to say I’m anxious to try the long announced java plugin for 64bit platforms. I’ve been using icedtea 6 on gentoo for a while, but as I need a Sun JVM for professional stuff I’m glad this update has finally arrived. Curious to see if it lives up to it’s expectations.

Besides all that, the included improvements seem quite numerous (take a look at the release notes)

Can’t find the Capabilities prefs pane or Classic Update?

Wednesday, December 17th, 2008

Eclipse 3.4 Ganymede introduces a new UI for software updates.

In order for the Help->Software Updates submenu to show up again:

  1. install the Eclipse SDK plugin if needed
  2. enable Classic Update in Preferences->General->Capabilities

Easy as eating … fries! :-)

64bit Flash plugin for Linux, finally!

Monday, November 17th, 2008

Pigs seem to be able to fly as Adobe today released a preview 64bit release of it’s Flash plugin!

Are the days of using nspluginwrapper finally over? I suppose we can’t expect too much of a preview but those days seem to be coming!

If now we get a fast 64bit native java runtime (with a working -client option please), I guess the productive life in the 64bit Linux world is finally no more painful than the 32bit world.

Kudos Adobe, this is a step in the right direction!

Now, please also create a Linux version equivalent (or even something better maybe) to Digital Editions and I can actually take advantage of my digital subscribtion to www.standaard.be to read the entire paper digitally.

The pain of setting the classpath through the Jar Manifest

Wednesday, October 8th, 2008

I’ll keep this short: jar manifests suck. I just found out a jar wasn’t loaded as it was supposed to because my manifest classpath entry was 70 chars long (including the first space!). All other lines were 71 chars long, except this one because the entry was finished, so I was missing one space.

Netbeans handles this nicely when I build my app consisting of a number of projects with jar dependencies. Everything ends up ready to run in the dist dir of the main project root. Neat and simple. In Eclipse I seem to overlook the ability to export a Jar with it’s dependencies’ classpath preconfigured & packaged alongside the project code. I mean, am I *supposed* to do this myself?

I guess I really need to upgrade to using ant or maven and automate these kinds of things … and I will! Euhm … soon!

Since this is a clientside project, I’ll finally make the step and get the right kind of certificate to sign my code and WebStart enable the entire thing. And unless I solve these issues, I’ll return to netbeans for that purpose, although MyEclipse finally enabled me to stick with Eclipse :(

Until I switch to something automated of course :-)

Tired now. Need sleep.

Nite nite.

PS: I was about to reread but I’m too tired, so sorry, it’s probably badly written and ill-structured (or something)

‘Fixing’ the slow JFileChooser on Windows XP

Friday, September 26th, 2008

Ever used a Java Swing app on Windows XP that seemed to freeze when you open a JFileChooser dialog? Apparently it’s caused by calls being made to Windows’ infamous integrated ‘compressed folders’ utility when files are recognized as archives.

The bad news is that every stable Sun JVM on Windows XP up to today suffers from this issue.
The good news that the issue has been f fixed in Java 1.6u10b07. Although I don’t presume to know the entire history of this bug, it seems a little sad to see this one was reported against release 1.4.2.

To fix on java versions predating 6u10b7, the only fix is effectively unregistering the zip folder dll from windows. Since I won’t quite use 6u10 until it’s GA and I’ve been a happy 7zip user on every OS I use for quite some time now I decided to go for the uninstall.

To unregister (and disable ‘Compressed Folders’):
regsvr32 /u %windir%\system32\zipfldr.dll

If you decide for some reason you can’t live without it and want to re-enable, execute again from a cmd :
regsvr32 zipfldr.dll

and you’ll be sending things to compressed folders before you know it :-)