re dynamic classloading and headless behaviour ... AFAIK, the call to load X (native) libraries happen at link time, which in the java world is basically on classloading. So you CAN get around X loading be ensuring that class loading of ANY awt class does not happen till the method is called. Note, however, that importing a class will trigger classloading when the importee is loaded .. which means basically that you will have to call methods via relflection as well (ie, Class.method etc), you cant just create the class dynamically and cast. So u have to be very careful .. importing a class that imports a class that imports a class .. that imports an awt class will disable headless operation.
Also, no exception is thrown when the X libs are not found, the jvm basically exits (at least in 1.2 which i have experience of ). All this makes it very dicey, so tho it is possible to get around it, i would suggest one does it only if absolutely necessary, and then it is well tested. If is of course a very big deal to ensure that POI can be used in headless environments with jdk1.2 and jdk1.3. my 0.02 Regards - Avik Quoting "Andrew C. Oliver" <[EMAIL PROTECTED]>: > On Sun, 2002-04-28 at 18:08, Drew Varner wrote: > > I am taking up too much mailbox space with my philosophy here, so I'll take > it > > offline for anyone interested in the discussion. The truth is it isn't a > big > > deal. Sorry folks =-) > > > > *shrugs* discussion is always fine when its intellectual. (We try to > avoid the Apache trademark flamefests a bit more around here) > > > > > Agreed. I don't think POI is responsible for displaying images. I focus on > > > manipulate. I'd probably return an instance of BufferedImage, which is just > an > > image in memory. Now we have access to all of Java's methods for > manipulating > > images (scaling, transforming to other formats, drawing on, etc.). I only > know > > how to write against AWT, Java2D and Java Advanced Imaging. I have never > used > > Swing in my life, and I am in no hurry to start. > > > > Swing still calls X (via AWT). Swing is on top of AWT basically in many > respects (yes you don't have the native peers for everything but lots of > things in swing just pass through to AWT) > > > > Well WHAT can you do with the WMF? The POI kind of thing to do with it > > > would be to read one and provide an API for manipulating it, create one > > > from scratch and provide an API for manipulating it. But I agree this > > > seems to be basically a Batik overlap and maybe we can just depend on > > > Batik for graphic formats and POI can do the specifics for storing it > > > for a given format. (Storing an image in HSSF is non-trivial). > > > > See above for what I think manipulation of an image is (scale, rotate, > > transform, etc.). Mainly, you should be able convert it to another format, > a > > Java-friendly format. We don't return other properties as ULONGs or *voids. > > > Jakarta has a strong server-based lean. A M$-specific vector-based format > > > doesn't have a role in a server environment. SVG would be a nice fit. > However, > > SVG rendering is via plugin on most browsers. However, Java can write PNGs > and > > JPEGs. It seems to me allowing us to transform WMF into server and Java- > > friendly images images is good. > > > > Well if there was an HIF for playing with windows-specific-images > (seperating the concern of decoding the Image), I'd not really care too > much if was tied to X. You'd want to make it as untieable and well > encapsulated as possible but what we want to avoid is having HPSF or > HSSF or HDF call X but if there was a general port of WMF or DIB or > whatever then it could be tied to X. (Or at least until I needed it > untied and got around to untying it) > > > > POI isn't an API for viewing the formats, its for creating, parsing, > > > modifying. Go write a Spreadsheet and use POI for the Excel > > > compatibility for instance. We're not really here to make GUI apps. > > > > I agree. However, POI can't parse WMF. It understands nothing about it. We > > > can't modify it (unless we map it to an image). Someone will need this sort > of > > functionality for charting I'd think > > > > Right, and it would be nice to have a library for POI to parse WMF. > > > > Just Jakarta = Server-side java. > > > > I agree. See above. > > > > Well the trick here is that a Server might NOT have a GUI. Only really > CRAPPY sorry excuses for 32-bit extensions to 16-bit shells for 8 bit > operating systems originally written for 4 bit processers by 2 bit > company trying to pass themselves off as server operating systems > guarantee you a GUI. Granted in 2 years it wont make no nevermind > anyhow. (1.4.x) > > > > Remember POI's being used by Banks and other folks on servers > > > that may or may not be graphical in nature. In fact one gentleman is > > > using it on an AS400 and would have to serial to a PC to call to AWT > for > > > instance. Saying 1.4 will fix it all is a bit well...improper. Most > > > folks won't be switching (and rightly so) to 1.4 until its had time to > > > bake (read: they fix all the really STUPID bugs). Just because this is > > > not a requirement for you doesn't mean its not important. You speak of > > > reinventing the wheel, I'm willing to reinvent the wheel to be round > > > instead of square (like the one Sun seems to have invented in this > > > case). > > > > It seems that if I use dynamic class loading in methods with AWT > dependencies, > > the man at the bank will never know the difference. Now, if he calls a > method > > to transform it to a java.awt.BufferedImage, he'll know it. Otherwise, he > > > won't. Should we give him he choice? I generally don't like dynamic class > > > loading, but this seems like a good case for it. > > > > But you need to not import java.awt.** in order to accomplish this. > Probably the best thing is to dynamically load YOUR class rather than > the AWT class. Better yet have the class available take in the > bytestream and create the image. That seems to separate the concerns > nicely. > > > > Keep coding and having fun. Chin up > > > its only life. > > > > No problem. It seems by going through this exercise I'll be in a better > > position to know how to do the conversions anyway. There is no question > > that "I" can extract thumbnails, modify them, etc. So, the discussion from > my > > point of view is academic. I'd be surprised if anybody accesses a thumbnail > via > > the API. It just seems to go with the "spirit" of the project, though I > > understand people tend to lose their mind when you break their code, and I > > > can't blame them. > > > > eh? > > > In the end, I think the important thing is that a user does not have a > > dependency against Batik to manipulate thumbnails. I think the best answer > is > > moving it to the Commons. This will allow both projects to use the tool. > It'd > > be useful in many other applications (CAD, drawing, format conversion > tools, > > UML tools etc.) for importing WMFs that might not want to depend on huge > JARs > > for simple image conversion. The solution is probably administrative > (talking > > to Batik folks) rather than coding. And, it doesn't affect me, I just > enjoyed > > the discussion. Now, folks with grand schemes for a Java-based spreadsheet > > > might think more of my theories down the road. > > > > Agreed? > > > > +/- - What I think would be optimal is having a windows specific image > library under POI in its own package. It could be tied to awt until > someone scratches the itch. > > Anyhow, don't tie HPSF/HDF/HSSF/POIFS to AWT and my objections are > satisfied. Even if its by providing methods for optionally loading > thats fine. Just test and make sure. Thats all I care about. (that > and that we don't end up with GUI apps in the mainstream of things). > > -andy > > > > - Drew > > ___________________ > > Drew Varner > > [EMAIL PROTECTED] > -- > http://www.superlinksoftware.com > http://jakarta.apache.org/poi - port of Excel/Word/OLE 2 Compound > Document > format to java > http://developer.java.sun.com/developer/bugParade/bugs/4487555.html > - fix java generics! > The avalanche has already started. It is too late for the pebbles to > vote. > -Ambassador Kosh > >
