 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / First Aid / October 2009run two jre versions - conflict
Hello, I have a program (McKesson Physicians' Portal) which requires an older jre version. I can install this version directly from the portal,downloading jre 5 (jre-1_5_0_05-windows-i586-p.exe) directly from their site. I have to have already uninstalled any other versions of jre in order to do this. During the install, I am told to unckeck browser registration. (The portal works only with IE.) This works fine and once I have uninstalled the newer versions and installed v5, I can use the applet to access the material I need from the portal through IE. The problem is that I can't install a later jre version, such as version 6 update 16 (jre-6u16-windows-i586-s.exe) without the newer one apparently overwriting some part of the old one, which makes it impossible to access the applet through IE. I have tried going into the respective control panels for the two versions (in c:\program files\java\) and changing what I can on the various tabs to try to make the applets work through the older version. But either this isn't working, or I'm not doing it right. I also went to this site and tried to learn from it, but no success: http://mindprod.com/jgloss/jre.html I've also tried unchecking the box to use the newer java version in IE\tools\internet options\advanced. Didn't help. I've put a number of days into this effort and now I'm ready to accept defeat! Any thoughts, links or advice would be greatly appreciated. Of course I probably could just live with the older version alone on the system. But it would be great if I could figure out what the problem is. Many thanks. Jack > Hello, > [quoted text clipped - 4 lines] > of jre in order to do this. During the install, I am told to unckeck > browser registration. (The portal works only with IE.) Combining 'requires a previous version' with 'only works in IE', I can surmise that the software is inherently broken. My advice is to tell them to fix their broken software. -- Andrew T. pscode.org > > Hello, > > > I have a program (McKesson Physicians' Portal) which requires ... > >...jre 5 (jre-1_5_0_05-windows-i586-p.exe) ... > Combining 'requires a previous version' with > 'only works in IE', I can surmise that the software > is inherently broken. ..and insecure. Checking <http://java.sun.com/j2se/1.5.0/ReleaseNotes.html> indicates there were at least 4 security updates between _05 and the latest 1.5 version, _20. Any company that demands use of a JRE which has publicly defined security vulnerabilities, is not one I would deal with. -- Andrew T. pscode.org I was inspired to take this further, and found my way to.. <http://sites.mckesson.com/doctors/connectivity.aspx> They offered a 'contact us' form, so I put the following text in it. ------ I just replied to one of your unfortunate users on usenet, advising them not to use your software. The thread can be found here. <http://groups.google.com.au/group/comp.lang.java.help/browse_frm/ thread/e04bbdfa28181d00> It seems you are providing a JRE that is lacking the fixes for security vulnerabilities that were introduced in at least 4 later updates. Do you have any comment on this travesty? Please reply to the thread if so. ---------- After pressing submit, the message was.. "Requested page could not be found" These people are 'class a' bozos. -- Andrew T. pscode.org >These people are 'class a' bozos Andrew, No argument. I am told by a hospital IT person, that McKesson will have all of this corrected "in the future",and he thinks it will be within the next few months. They have been working with jre v1.4 up to now. Meanwhile, I need to use the program on a daily basis. I had hoped there would be a workaround until their programmers get their software up to date. I thought I might be able to configure the 1.5 version to do the applets for the portal, and the newer version to to applications, etc. I'll keep playing with it. Thanks for your assessment and intervention. Jack > >These people are 'class a' bozos > Andrew, > > No argument. I am told by a hospital IT person, that McKesson will > have all of this corrected "in the future", and he thinks it will be > within the next few months. I see they're looking for a software engineer with Java experience. > They have been working with jre v1.4 up to now. Meanwhile, I need > to use the program on a daily basis. I had hoped there would be a > workaround until their programmers get their software up to date. I > thought I might be able to configure the 1.5 version to do the > applets for the portal, and the newer version to to applications, > etc. Would a virtual machine allow you to contain the vulnerable JRE more safely? It's a little resource intensive, but I've been pleased with Sun's latest VirtualBox <http://www.virtualbox.org/>.  SignatureJohn B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews> > ...Would a virtual machine allow you to contain the vulnerable JRE more > safely? Quite possibly. Unfortunately, the 'requires IE' part of the equation indicates that it interacts with IE specific JS. I can think of no other reason that the applet would require IE. One /possible/ work-around solution might be to get IE working with the particular JRE required, another internet browser using the latest version, and to use IE specifically and *only* for that applet. This of course assumes that the people who made the applet are not intending to trash the user's system (which is quite plausible) and that they are competent, which is less plausible given what has already come to light. As an aside, I noticed they had a branch in Australia, so I popped them a note by email, offering my services. I cannot imagine they will be keen on that prospect, after I publicly trashed them and their software, but hey - the ball is in their court. -- Andrew T. pscode.org > As an aside, I noticed they had a branch in Australia, > so I popped them a note by email, offering my > services. I cannot imagine they will be keen > on that prospect, after I publicly trashed them > and their software, but hey - the ball is in > their court. They won't have seen your comments - to do that they'd have to read this newsgroup, and that would imply a desire to keep up to date with what's going on in the Java world. You can rest easy. SignatureLew >One /possible/ work-around solution might be to get >IE working with the particular JRE required, another >internet browser using the latest version, and to >use IE specifically and *only* for that applet. John, Andrew Unfortunately a lot of very unsophisticated users have to use this system, and any complex solutions won't be possible. In the past, the program applet would run with jre 1.4, and that version would co-exist with 1.5. Now that the applet works with 1.5, it will not co-exist with 1.6. That's the real problem. I keep thinking there is some way to configure the two versions 1.5 and 1.6 so that the McKesson applet will work in IE using 1.5, and allow other applications to work with 1.6. I have tried what I think are most if not all the possibilities of configurations within the respective jre control panels. I appreciate the thoughts and suggestions. Jack Andrew Thompson wrote: >> These people are 'class a' bozos > No argument. I am told by a hospital IT person, that McKesson will > have all of this corrected "in the future",and he thinks it will be [quoted text clipped - 6 lines] > 1.5 version to do the applets for the portal, and the newer version to > to applications, etc. Just to put this in perspective, Java 1.4 hit its "End-of-Service-Life", i.e., retirement, on October 30, 2008, and Java 5, which has been out for over five years now, will hit its end of life this coming October 30. As Andrew pointed out, they haven't even kept up with security patches, for Pete's sake. I don't know how they can lock compatibility to an older version of Java within a major release; that has to be some code they've written to do that. SignatureLew >I don't know how they can lock compatibility to an older version of Java >within a major release; that has to be some code they've written to do that I have been told that the program will work with the newest jre version "soon". Jack Lew wrote: >> I don't know how they can lock compatibility to an older version of Java >> within a major release; that has to be some code they've written to do that > I have been told that the program will work with the newest jre > version "soon". But still, how did they manage to do that? I don't know how. SignatureLew You can install old and new versions of JDKs. I have never seen any sign of overlap. What I think is happening is IE is using the new JDK even though you want it to use the old one. I would try firing up the Applet with Java Web Start where you have finer control of the JDK version. See http://mindprod.com/jgloss/javawebstart.html SignatureRoedy Green Canadian Mind Products http://mindprod.com I advocate that super programmers who can juggle vastly more complex balls than average guys can, should be banned, by management, from dragging the average crowd into system complexity zones where the whole team will start to drown. ~ Jan V. > would try firing up the Applet with Java Web Start where you have >finer control of the JDK version. > >See http://mindprod.com/jgloss/javawebstart.html Roedy, I will work on this. Many thanks. Jack >I have a program (McKesson Physicians' Portal) which requires an older >jre version. This is odd. The restriction is probably artificial, someone being conservative, not wanting to deal with the possibility of an incompatibility, not because there actually is one. You might ask the manufacturer if they could take out the bounds check for you. The usual restriction is that you must have version X or higher since the program uses new features of version X. SignatureRoedy Green Canadian Mind Products http://mindprod.com I advocate that super programmers who can juggle vastly more complex balls than average guys can, should be banned, by management, from dragging the average crowd into system complexity zones where the whole team will start to drown. ~ Jan V. >You might ask the manufacturer if they could take out the bounds check >for you. Roedy, This is being done through the IT person at the hospital which uses this software. I'll report back how it is resolved, but it will probably be a while. Thanks Jack >This is being done through the IT person at the hospital which uses >this software. > >I'll report back how it is resolved, but it will probably be a while. You might decompile/disassemble to look for the version check, and defang it. If all still works ok, you can even had the author the patch you would like him to officially apply. see http://mindprod.com/jgloss/decompiler.html http://mindprod.com/jgloss/disassembler.html Look for code of the form: String ver = System.getProperty( "java.version" ); It should also be possible to fool the program by overriding the System property with the -D option on the command line in a JNLP file. I don't know if the JRE defends itself against that. see http://mindprod.com/jgloss/javaexe.html See http://mindprod.com/jgloss/properties.html SignatureRoedy Green Canadian Mind Products http://mindprod.com When you lose interest in a program, your last duty to it is to hand it off to a competent successor. ~ Eric S. Raymond (born: 1957-12-04 age: 51) The Cathedral and the Bazaar >decompile/disassemble to look for the version check, and >defang it. Roedy, That is pretty heavy stuff. It looks exciting and I'll keep your links and perhaps play with it when I have some more time. But I don't think that's going to help the many users who will need to use this program "out of the box". We link to and access it from their website, in any case. No program is installed on the various computers. Right now, the only way I'm getting it to work is to have only jre 1.5 on the machine. I'll report back if I have any thing to add or results. Thank you for your input. Jack >We link to and access it from their website, That adds another layer of restrictions. I think though you can still likely run in with your own JNLP file. I have not tried that. Andrew might know. SignatureRoedy Green Canadian Mind Products http://mindprod.com No flying machine will ever fly from New York to Paris. ~ Orville Wright (born: 1871-08-19 died: 1948-10-30 at age: 77) 1908 We see that same conservative pessimism in those crafting todays computers and computer tools. They are overwhelmed by the details of producing even todays solutions. You need young, over-confident people who dont know too much to chart the course ahead. This is especially true of global warming where the current generation has entirely given up hope of a green planet and sustainable human survival. On Oct 17, 11:35 am, Roedy Green <see_webs...@mindprod.com.invalid> wrote: > >We link to and access it from their website, > > That adds another layer of restrictions. I think though you can still > likely run in with your own JNLP file. I have not tried that. Andrew > might know. Theoretically yes. I had no problems in my JNLPs hot-linking to Jars on other sites. As mentioned to John Matthews upthread, I suspect the reason the software vendor demands use in IE, is that the applet is interacting with IE specific JS. An applet that relies on JS interaction, cannot be launched free of the browser and still work. Since the app. itself is only open to paying customers (AFAIU), we are unable to access the original page where the applet lives, and further analysis (of dependencies etc.) is not practical. -- Andrew T. pscode.org Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2010 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.