Re: Scott's Excel stuff and Giovanni's XLPARSE2

Hi Craig,

The main thing is that people might need to use different versions of the JAR files. This includes the possiblity that a 3rd-party application might want to use a different version of the same JAR files than you use.

For example, I buy a software package that reads a spreadsheet as a means of "importing" records into the software. (Software like this is more and more common these days.) The vendor decides to use POI for this, and includes the JARs in their software installation, and a CLASSPATH in their job (which runs in batch.)

An operator is installing and trying to get this software to run, and it just won't run. They can't understand it. The vendor can't understand it. It all works so well for everyone else! Finally, they call me (I get all the tough jobs) eventually I determine that the vendor is using POI, and that it's a different version that I'm using. But, since my POI was in /qibm/userdata/java400/ext, it took precedence over their classpath.

They should be able to develop/test POI with whatever version they want. Since they supply their own jars, and their own classpath, it shouldn't matter what I'm using. But it did because of the "ext" directory.

Using "ext" precludes you from ever using software packages that incorporate POI! Ouch.

Same situation can happen when I'm testing/developing with one version of POI, and another version is in production. (Assuming you do both production and test on the same LPAR.. as many do.) This causes a conflict. It probably won't create as much confusion (after all, as the developer I'll probably know what's going on, and can correct it.) But still a problem.

Using /QOpenSys/userdata/java400/ext is like putting your programs into the QSYS library to guarantee that they are in the library list. It'll almost certainly work -- but it's not a good idea.



Craig Pelkie wrote:

Scott

What is your reasoning behind not wanting to put code into ext? Is it primarily to prevent the issue of duplicate classes, and the incorrect class being loaded?

Are there any instances where you would recommend or use ext? For example, I prefer to put other databases' JDBC drivers there.

Thanks
Craig Pelkie


----- Original Message ----- From: "Scott Klement" <midrange-l@xxxxxxxxxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Sent: Monday, March 22, 2010 12:43 PM
Subject: Re: Scott's Excel stuff and Giovanni's XLPARSE2

Okay, so I did say it more recently than 2004...

But if it helps, I really really really regret saying that! :)

When I speak about this stuff, I tell people not to use the "ext"
directory, and my recent articles (like the following one) explain how
to set up an IFS directory structure and put it in your CLASSPATH.

http://systeminetwork.com/article/new-poi-release-brings-excels-xlsx-support-rpg

Unfortunately, when I say something st00pid and it gets published, it's
hard to take it back :)


On 3/22/2010 1:03 PM, Dennis Lovelady wrote:

I don't suppose it could have been from this July, 2007 article? "POI
Updated to Version 3.0.1"
http://systeminetwork.com/article/poi-updated-version-301/

Quoting: "Personally, I prefer to put the POI JAR files in the Java
"extensions" (/qibm/userdata/java400/ext) IFS directory. Once that's done,
they're installed and there's no need for me to monkey with my CLASSPATH,
because any JAR file in the extensions directory will automatically be found
and used by the JVM. Basically, any JAR file in that directory is considered
a "public tool" available to any Java software on the system."

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.