my2cents

20. May, 2009

Taking the SCJP

Filed under: Java,Software Development — frightanic @ 23:53

This blog now resides at http://www.frightanic.com/. It will be discontinued here…

Reading a book on the Sun Certified Java Programmer (SCJP) test is interesting and worthwhile, but the test itself is bogus.
Says who? I do…

I took the SCJP for Java 2 many many years ago and subsequently also passed the SCJD and SCWCD tests. So, I feel I experienced a fair share of the Sun certification universe.

SCJP is known as the “API test” and its successful completion is the basis for all other Sun Java certificates. You’re expected to be familiar with many of the basic Java/OO concepts and APIs – sometimes down to the method signature. As such, passing the test shouldn’t require at lot of studying for any serious Java engineer since this is our daily bread and butter.
So, going through a certification prep book should hopefully not teach you a lot of new stuff (i.e. things you weren’t previously familiar with) but rather fill your know-how gaps. And that’s the interesting part. You might uncover surprising aspects of the JLS (Java Language Specification) which can be valuable.

However, it’s the way questions and code samples are formulated in the test that hamper the significance of its results. The time limit for the full Java 6 test is 210min (yes, that’s 3.5h!) and it consists of 72 questions. While you may finish a lot quicker it certainly is a primary test for your ability to concentrate in a test center. Furthermore, the majority of the questions contain code samples that are outright silly. You’ll see code that no sensible programmer would ever craft like that – even if the JLS allowed it.
You job would then be to find the missing ‘;’, the missing ‘static’ modifier, the illegal [] in an array declaration, the overridden instead of overloaded method, the illegal auto-boxing, the… you name it i.e. mainly stuff the compiler would report anyway. Finding the correct answer has become harder over the years because for most questions two of the possible answers nowadays are “Doesn’t compile” or “Fails at runtime”.

So, practicing for the test is not so much about learning Java as it is about getting accustomed to this type of questions and finding a (personal) strategy to tackle them.

All in all, I don’t think a Java test which a good Java developer might still flunk has a lot of significance. And passing this test doesn’t necessarily mean that you’re a good developer, either. Pity.

2. May, 2009

There’s no such thing as a “static inner class” in Java

Filed under: Java,Software Development — frightanic @ 16:53

This blog now resides at http://www.frightanic.com/. It will be discontinued here…

It was only recently after many years of Java programming that I found out that there’s no such thing as a “static inner class”. Such classes are called static nested classes.

-> http://www.coderanch.com/t/442837/Programmer-Certification-SCJP/certification/Members-inner-classes

25. January, 2009

GWT widget libraries, a market overview

Filed under: Java,Software Development,Web Authoring — frightanic @ 15:37

This blog now resides at http://www.frightanic.com/. It will be discontinued here…

After many hours searching the Internet for GWT widget libraries, analyzing them, and taking notes I thought I might as well publish my findings here. Feel free to comment and point out inconsistencies.

At the moment the market seems to be split into two segements:
– a few small or medium-size, low-key libraries with little activity
– the whole “Ext” gang

However things change very quickly, in a matter of months, and the end of 2008 saw the advent of a new-kid-on-the-block: SmartGWT.

Small, or medium-sized libraries

  • GWT-SL/WL, a collection of server- and client-side tools. No real show case that demonstrates the power of the library is available. Last minor release in December 2008. Little SVN activity over the entire course of 2008.
  • GWT Tatami, based on the DOJO JS framework. Show case isn’t impressive, but project is active. Continuous SVN activity. Road map for first half of 2009 available.
  • GWTLib, continuous but little SVN activity. Offers hardly anything else but but table-centric widgets.
  • GWT Tk, tbd
  • Rocket GWT, tbd
  • “vanilla” GWT, Google’s on-board GWT widgets. Nothing fancy, but clean and slick.

The “Ext” corner
A long time ago (think Internet time ;-)) a guy called Jack Slocum built an extension to Yahoo’s YUI widget library named YUI-Ext. It evolved and became independent, Ext JS was born and with it a new company: http://extjs.com. The library quickly became very popular.
Once GWT was released people started writing widget libraries for it. Boston-based Sanjiv Jivan started GWT-Ext and based in on Ext JS. Darrell Meyer wrote MyGWT, a pure GWT widget library which shared the Ext JS l&f. It was voted #1 widget library one year ago.
In April 2008 things became very nasty an confusing when Jack Slocum changed the Ext JS license from LGPL to GPL thereby forcing GWT-Ext to stick with Ext JS 2.0.2 which was the last version available under LGPL. Furthermore, he hired Darrell Meyer who brought his MyGWT as a dower into the relationship. As a result, Ext JS published its own GWT widget library called Ext GWT. Now developers had the choice between GWT-Ext (full OSS with LGPL) and Ext GWT with a dual-licensing model. The GWT widget “war” (see references 1-5 below) turned many away from Jack Slocum’s Ext JS because they disliked the way the company treated the GWT community.
On November 26th, 2008, the game changed again when the GWT-Ext crew announced that they would no longer build major new features but instead be migrating to SmartGWT, a library created by GWT-Ext developer Sanjiv Jivan . SmartGWT 1.0 had been announced only two weeks earlier.

[1]http://www.jroller.com/sjivan/entry/my_response_to_jack_slocum
[2]http://pablotron.org/?cid=1556
[3]http://www.gwtsite.com/ext-gwt-gwt-ext-what-now/
[4]http://ajaxian.com/archives/to-gwt-ext-or-to-ext-gwt
[5]http://gwt-ext.com/license/

6. September, 2008

Inserting data into an Oracle LONG field with Spring JDBC

Filed under: Java,Software Development — frightanic @ 17:32

This blog now resides at http://www.frightanic.com/. It will be discontinued here…

I struggled to update the content of a LONG column in an Oracle database with Spring JDBC. However, (in retrospective) this is more of a general JDBC problem than a Spring problem.

The problem first occured when I tried to use a regular SQL update statement to save a few thousand characters in that LONG field.

simpleJdbcTemplate.update("update mytable set content = ? where id = ?", new Object[] { o.toString(), o.getId() });

Hence, I tried to execute the same statement in a SQL editor, Oracle’s SQL Developer in my case, and got “ORA-1704: string literal too long” as a feedback from the database. Further analysis revealed that the LONG datatype has been deprecated in Oracle ever since 9i. It can hold 2GB max. but you’re encouraged to use CLOB instead. Some poking around the JDBC pages at oracle.com revealed sample code that describes how to manipulate LONG fields: http://www.oracle.com/technology/sample_code/tech/java/sqlj_jdbc/files/basic/LongSample/Readme.html.

Now, whether the below code is optimized or not is yet to be seen. It solves my problem, though.

final LobHandler lobHandler = new DefaultLobHandler();
final byte[] contentBytes = o.toString().getBytes();
final InputStreamReader clobReader = new InputStreamReader(new ByteArrayInputStream(contentBytes));
simpleJdbcTemplate.getJdbcOperations().execute("update mytable set content = ? where id = ?", 
    new AbstractLobCreatingPreparedStatementCallback(lobHandler) {
    protected void setValues(PreparedStatement ps, LobCreator lobCreator) throws SQLException {
        lobCreator.setClobAsCharacterStream(ps, 1, clobReader, contentBytes.length);
        ps.setString(2, o.getId());
    }
});

15. April, 2008

Java SimpleDateFormat and 4-digit year vs. 2-digit year

Filed under: Java,Software Development — frightanic @ 23:35

This blog now resides at http://www.frightanic.com/. It will be discontinued here…

At the end of an already long day a co-worker and I recently came across the problem that

new java.text.SimpleDateFormat("dd.MM.yyyy").parse("03.03.08");

does not return March 3rd, 2008 but March 3rd, 0008 instead.

As any decent engineers would, we headed for the respective API documentation right away to see whether there was an explanation for this behavior. Like any bad engineers, however, we didn’t pay close enough attention to the details in the documentation and tried to fix the problem with the wrong tools. Since our customer forces us to develop for the WebSphere platform, hence for an IBM Java runtime, we even suspected that this might be the cause for our confusion. Shame on us! We were barking up the wrong tree. It’s all there in the JavaDocs if you read it carefully: http://java.sun.com/j2se/1.5.0/docs/api/java/text/SimpleDateFormat.html#year:

“For parsing, if the number of pattern letters is more than 2, the year is interpreted literally, regardless of the number of digits. So using the pattern “MM/dd/yyyy”, “01/11/12″ parses to Jan 11, 12 A.D.”

Ok, that’s the explanation, but what is the solution if you need “03.03.08” or “03.03.2008” to be parsed into March 3rd, 2008? As so very often I needed to put some distance between myself and the problem (it dawned on me in the train on my way home). The pattern in this case needs to contain fewer or an equal number of letters for the year than the actual string to be parsed. The pattern “dd.MM.yy” interprets both the above examples as March 3rd, 2008.

For testing purposes I wrote a few lines of code to observe the behavior of the parse() method.

import java.text.*;
public class DateTest {
    private static final DateFormat parseFormat = new SimpleDateFormat("dd.MM.yy");
    private static final DateFormat formattingFormat = new SimpleDateFormat("dd.MM.yyyy");

    public static void main(String[] args) throws ParseException {
        test("3.3.08");
        test("3.3.2008");
        test("03.03.08");
        test("3.3.08xx");
        test("32.3.08");
        test("3.3.xx08");
    }

    private static void test(String dateString) throws ParseException {
        System.err.println(formattingFormat.format(parseFormat.parse(dateString)));
    }
}

produces

03.03.2008
03.03.2008
03.03.2008
03.03.2008
01.04.2008 // obvious, due to default lenient behavior
Exception in thread "main" java.text.ParseException: Unparseable date: "3.3.xx08"
	at java.text.DateFormat.parse(DateFormat.java:335)
	at DateTest.test(DateTest.java:16)
	at DateTest.main(DateTest.java:12)

4. July, 2007

How Java exceptions can fool you

Filed under: Java,Software Development — frightanic @ 23:15

My blog stats clearly indicate that many visitors find my posts through search engines. What is mostly queried are solutions or hints for software problems. That’s why I’ll keep posting solutions to interesting problems.

While deploying a Struts based application on a co-worker’s Eclipse/Tomcat installation we were faced with a nice ActionServlet exception (org.apache.struts.action.ActionServlet abbreviated as ActionServlet):
javax.servlet.UnavailableException: Parsing error processing resource path
/WEB-INF/config/salesstories/struts-config.xml
at ActionServlet.handleConfigException(ActionServlet.java:1035)
at ActionServlet.parseModuleConfigFile(ActionServlet.java:1014)
at ActionServlet.initModuleConfig(ActionServlet.java:955)
at ActionServlet.init(ActionServlet.java:470)

We knew that the path to struts-config.xml was correct, but we couldn’t get to the root of the problem. So, we started debugging ActionServlet#parseModuleConfigFile(). We found that the “real” exception was a SaxParseException due to “premature end of file”. That left us even more puzzled as struts-config.xml was a perfectly valid XML file.

So, we started to play around with that file. Erase the encoding declaration, remove certain segments, etc. Nothing helped. Then I discovered that the SaxParseException with the misleading message “premature end of file” carried a InvocationTargetException as its cause. Now that started to look interesting. That exception’s message brought me to the real problem: “Unsupported major.minor version“!

My co-worker had set up Eclipse to use a Java 5 JDK to compile his code, but had run Tomcat using a Java 1.4 version. Ok, this doesn’t necessarily cause problems unless you set the compiler’s compliance level to 1.5, which my co-worker had done.

27. June, 2007

Why ServletRequest#getRemoteAddr() returns 127.0.0.1

Filed under: Java,Software Development — frightanic @ 00:39

When I found the reason why my Servlet container returns the “wrong” remote address I had to smite my forehead – long and hard. As so often the container is right and I was simply on the wrong track. It’s soooo obvious, Jesus…

If you access your application using the URL

http://localhost:port/

, you will get the remote address as 127.0.0.1 (local host address i.e. loop back address). Instead, try accessing the URL using your system/server name to get the desired output

http://systemname:port/

Yet another lesson learned I’ll never forget.

16. June, 2007

“Content is not allowed in prolog” for XML in Eclipse

Filed under: Java,Software Development — frightanic @ 23:19

This blog now resides at http://www.frightanic.com/. It will be discontinued here…

Sometimes life as a software developer is almost too painful for me to bear. It’s ok to debug a piece of code for hours or to rack one’s brains over a problem instead of getting a good night’s rest; that’s part of the deal. What I can’t stand is solving a problem after hours and realizing that I had been barking up the wrong tree all the time.

While working on my first Sun SPOT project (blog posts on that are ahead) with Eclipse, the ANT editor all of a sudden reported an error on an XML build file: “content is not allowed in prolog”. While I was vaguely familiar with the meaning of it I could not see what was wrong with the XML file. For hours I searched the Internet, played around with my Eclipse preferences, and studied the first few lines of my build file. I loaded the file into the XML editor to confirm that it was valid indeed. I also loaded it into XmlSpy to double check. I did the right thing but missed to draw the right conclusions. As an XML document the file was ok, but as an ANT file it obviously wasn’t.

It was only after too many hours that I started stripping down the file, removing everything that wasn’t absolutely necessary. The error disappeared. So, I started removing individual lines to find the hot spot. When I stumbled upon an ANT <import> tag it finally dawned on me: the error was absolutely correct, but it simply referred to a different file. It was the imported file that couldn’t be parsed.

Yes, lesson learned. Indeed. I’ll never make that mistake again.

17. May, 2007

Compete, dude!

Filed under: Java,Software Development — frightanic @ 16:06

By coincidence I stumbled upon JavaBlackBelt last night – and was sucked in right away. Although I’m interested in competitions by nature, it isn’t that factor that fascinates me.
It’s the “forced self-fueling” of that platform that I find so convincing. In order to compete i.e. take exams you have to earn credits. And you only get credits if you participate activly by commenting on existing exam questions (0.5 points), proposing changes/corrections to existing questions (1 point), and writting new questions (2 points). No such thing as free lunch… However, the participation barriers are fairly low. It is fairly easy to collect credits. So, if you’ve only got the slightest interest in all those exams you stay and contribute your share. Since you’re encouraged to rate the questions you’re answering, the pool of available questions does not only grow (see credits above), but the quality of those questions are assessed by the “community” and not by some anonymous admin. Close to perpetum mobile. Well done!

19. November, 2006

Don’t push – pull!

Filed under: Java — frightanic @ 01:44

I recently had to teach/advise some fellow co-workers on XML parsing technologies (with Java). One of them knew nothing about XML at all – let alone XML parsing – the other was familiar with DOM and SAX basics. So, I started with a crash course on those both technologies, stressed their differences, AND introduced both of them to the XmlPull API.

In my opinion the XmlPull API which has led to StAX, the Streaming API for XML as per JSR-173, has not gained the recognition it deserves. Btw, check out the StAX crash course at Wikipedia for a neat introduction.

A “pull” based API that pulls relevant information from the XML tree – rather than “push”ing events as with SAX – lets you parse the document without the large memory consumption of a DOM and without the rather complicated event handling of SAX. It’s usually a very light API with some implementations specifically targeting J2ME applications. In my life as a software engineer I’ve seen too much abuse of DOM and SAX simply because people didn’t know that there are better alternatives available. I’ve found that XmlPull/StAX fits wonderfully for most use cases. It’s easy to learn & use, it’s extremly fast, and the memory footprint is minimal. What more do you want from an XML parsing API? Nothing more.

Next Page »

Blog at WordPress.com.