I have client which has a problem with printing from JAVA applications, using old Brother printers. The exception he gets is "Printer is not accepting jobs".
Other applications (not java applications) manage to print using these printers. He switched to a new printer (also Brother), without changing the driver and then it worked.
The idea is that he cannot change all the printers, also he does not want to reinstall all of them, as he has a network of hundreds of computers and printers.
I have read on different forums that there is a bug in java version 1.5 and 1.6, but this application only works with java 1.5 or above... so he cannot switch to java 1.4 (with java 1.4, the printing worked).
Can you please help me somehow and give me some possible solution to this problem?
Found a workaround using byte code manipulation at http://copy-con.blogspot.com/2009/12/printer-is-not-accepting-job.html
It appears that this is this bug. Unfortunately, it is marked as low priority, and since nobody has bothered to vote for it, it is being put off.
This forum thread gives some useful background (reply #11) and a workaround (reply #9) that ignores the printer status when trying to print a file.
If you want this bug fixed in Java 7, there is still time to submit a patch.
EDIT
I was aware that someone disputed the workaround, but I didn't get my head around the problem. Whatever, it should be possible to develop a better version, either using the same approach or a different one. If subclassing and using reflection to tweak private state don't work, then you can download the Java 6 source code, fix the bug and rebuild.
I'm sure it would be nice if someone had a solution for you, but lets be realistic. This looks like a problem that affects very few people. IMO, your best chances of success are:
self help,
paying for an Oracle support contract, or
hiring an independent technical expert.
Of these, self help has the best chance of giving you a quick resolution ... assuming you have people with the skills for doing this kind of work in-house.
Related
Before answering, please read all of this so you don't miss any details.
I have been looking on the internet for days, and trying to look through the javadocs, but I cannot find the answer anywhere.
How can I get connected devices through USB by using the java API. I do not want to use any libraries as they aren't reliable enough for the purpose I am using it for.
How do USB java libraries do it, what Java API does it use to connect to USB devices?
I know it may be complicated to actually work with it, but it will still be very useful.
I did seen the use of File.getRoots(), but it just gives storage, like C:/, H:/, etc. I want to be able to communicate with any USB device, like mouses, keyboards, custom hardware, etc.
Also include examples of code as well. It helps a lot in understanding it better. Make sure to also get to the point, it helps by saving time.
Update: I still have no clue on how to start.
Update 2: I found something with javax.usb, is it part of the java api, when I do say java api, I mean stuff that is already with java and where you don't need to download anything but the JRE. I am not sure as if it was, I would think someone would of mentioned something about it here. Going to try to find more into it. I can't find anything on the official java-14 docs, so guessing not.
Update 3: Haven't found an answer yet. Everything is redirecting to usb4java, which has not been updated in a couple years, 3 years in fact. Which is actually one of the main reasons I don't want to use any external library as it might get abandoned and will cause some issues with my code in the future. Hopefully someone can help soon, I desperately need an answer and the internet is no help and everything seems to redirect to libraries, which again, I don't want.
Update 4: Still on the hunt for an answer, still haven't found anything useful.
Update 5: I am seeing that I have tons of uses to do this, but don't know how to do it from scratch.
Update 6: Still on the hunt for an answer. I have been looking hard but found nothing. Looking through the USB4JAVA library code has been proven to not help much. But, I am going to keep looking, hopefully I find something soon. Found something though, it's libusb, a C program that USB4JAVA uses. Even though I won't use Java libraries, I might just use C libraries for Java, if that makes sense.
I need to activate SO_KEEPALIVE on an existing commercial java application because my firewall drops the connections after some inactivity. I do not own the source code so i can't change it (it would be rather easy when i had the source, just adding socket.setKeepAlive(true) ). So i was looking for some alternatives:
first i tried to work with libkeepalive.so ( http://libkeepalive.sourceforge.net/ ), putting this in de LD_PRELOAD seems to work for things like telnet & nc, but when i use it with my jrockit jvm, this LD_PRELOAD is totally ignored and every socket object is still being created without SO_KEEPALIVE
then i tried to search on the OS level if there was an option to activate this SO_KEEPALIVE per default for all TCP connections: unfortunately on redhat 6 enterprise there isn't such an option, although i found one for freebsd (net.inet.tcp.always_keepalive)
patching the linux kernel for adding this feature was a big no for my sysadmin ;)
searching for any java command line argument was unsuccessful
so last option: patching the existing JVM's java.net.PlainSocketImpl by adding setOption(SocketOptions.SO_KEEPALIVE, Boolean.valueOf(true)); in the protected synchronized void create(boolean stream) method and putting it before rt.jar via -Xbootclasspath/p
This last option works so far, but i'am a bit frustrated because i had to change a JVM for this! Anyone knows other / better ways to deal with such a problem? Why isn't there another simple way to activate SO_KEEPALIVE per default on all (java) applications?
Last question: why doesn't the java API let you set the keepAlive on serverSockets objects? It's only possible on Socket objects but in fact it also works on serverSockets
I run over the same problem and wondered why libkeepalive does not work. After some investigation I found, that libkeepalive has some 'limitations' (maybe somebody would call them bugs).
Because of the strange license (it comes with GPL), I decided to start over. The result is the libdontdie.
You can find a small Java test program there that works with (at least) openjdk7.
It is possible to redefine existing bootstrap classes during runtime using a java agent (http://docs.oracle.com/javase/6/docs/api/java/lang/instrument/package-summary.html) and ASM4 (http://asm.ow2.org/).
As you know the target class and method, all that is needed is to catch the return bytecode instruction of the relevant method and inject a method call before it.
This is one of the problems with commercial closed source software. If it doesn't work, your options are limited for fixing it. This is a COST of using closed source.
There is one obvious thing that you haven't tried yet.
Contact the support line for the product you are using and ask them to provide a solution for you. There may already be something in the product itself to solve this; e.g. some undocumented configuration option. Or they may be able to develop a custom workaround for your problem.
If customer support is unhelpful, you have a number of potential options:
You could attempt to reverse engineer the relevant part of the product (e.g. the place where it creates sockets), and figure out how to set "keepalive" by:
modifying one of their classes,
subclassing one of their classes, or
writing some kind of hook that uses reflection to dig out the socket objects from private variables, etcetera.
Reverse engineering could be a violation of your license agreement. However, if the reason you do it is to fix a problem in their code that makes it unusable for you, they would have a hard time convincing a court that what you were doing deserved to be punished. And the "court of public opinion" would most likely punish them if they tried that.
You could check your rights under your license agreement and relevant consumer protection law. Is the product "fit for use" if you can't get it to work for you?
You could threaten to cancel your support contract and stop using their product.
You could actually cancel your support contract and stop using their product. (And if you use a different product, prefer open source so that you don't get into the same bind all over again.)
The problems with your solution that "works" are:
You may have to repeat this every time you refresh your JVM.
It may interfere with other things in the application ... or other applications that use the patched JVM.
You can't redistribute this without violating your Oracle license ... unless you are using OpenJDK.
It is likely to make other folks who need to support your stuff nervous. (Understandably).
Last question: why doesn't the java API let you set the keepAlive on serverSockets objects?
You would need to ask the folks who designed the API. (Good luck with that!)
If you believe that this could and should be done, submit an RFE via the Java Bugs Database. Or better still, implement it yourself as patches to the latest OpenJDK codebase, and contribute the patch. Unlike your unnamed commercial product, Java is (basically) Open Source, and they welcome useful patches that improve the product.
Not sure if this is the right spot to ask but I'm having a Java issue. I have some Java code that works in Java 6 but not in Java 7, the error is:
java.lang.IllegalStateException: This function should be called while holding treeLock
Using Java6 works but a few of our external users are running Java 7. I figured out the error was caused by a call to validateTree(), which works in java6 but in Java7 we need to call validate() . When I test it locally it works.
Here's my problem, I started working at a big corporate and they won't let us make any changes to the code until its been very throughly looked at(my working change is going to take affect in April 2013) but until then our users are getting annoyed. I'm not the best with Java and was wondering if there was a way I could pass a runtime parameters to have this changed? or is there anything I can do without touching the code base?
I'm embrassed to ask this question since it could be solved easily by just implementing the fix but any ideas or direction would be very helpful.
Update: I'm ideally looking for something that I can get support to put in the java runtime parameter that would change all validateTree() references to validate().
Can I use runtime parameters to fix out of bad API calls in Java?
As a general rule, no.
In a specific case, you could look at the source code of the relevant classes Java 7 version of the class library to see if there is a backwards compatibility property.
Assuming that you can't find a fix, you are kind of stuck. I'd suggest:
Recommend to your customers that they use Java 6 until a fix can be issued.
Discuss with your management whether they can make an exception to their policy to allow this problem to be fixed urgently.
If neither of those works, then the real problem is between your customers and your management. You've done as much as you can do. Leave it to "the higher ups" deal with it.
You might be interested in my Answer to a related SO Question which touches on the issue of why they made this "breaking" change. My take is that the change is to force people to fix a class of insidious, hard-to-reproduce application bugs that cause strange UI behaviour. And that is a good thing ... in the long term.
Based on that, you could make a stronger case for issuing an out-of-band fix. The fix to replace validateTree() calls with validate() calls is actually a necessary fix for all Java platforms, not just for Java 7.
I have some Java code that works in Java 6 but not in Java 7, ..
One 'workaround' (I can see this being unpopular) is:
Deploy the applet using JNLP and use a J2SE version attribute of 1.6*. See Java Web Start - Runtime Versioning for details.
Note it will only work embedded in a Plug-In 2 JRE (a sub-set of 1.6 JREs) & even then, the client will likely receive warnings about 'uses an earlier JRE'. If the applet can be launched free-floating using JWS, it will work (supposedly) with around 1.4.2+.
The fix it to change the applet code to be compatible with both JREs, as outlined by kleopatra's 2nd comment & the answer of Stephen C.
The object returned by Component#getTreeLock() is used as a thread sychronization monitor. The documented thread-safety of certain methods was deprecated in the transition from version 6 to 7; an example is seen here. In general, verify that Swing GUI objects are constructed and manipulated only on the event dispatch thread. One of the approaches cited here may be helpful in automating the search for violations.
if (System.getProperty("java.version").startsWith("1.6")) {
...
} else{
...
}
I've got a big problem with IBM HACL for accessing a server which speaks 3270 protocol. The library keeps crashing, and our JNI wrapper is actually a bug-fixing layer for the poorly-implemented and poorly-documented library (and I suspect we have introduced new bugs with it too). Moreover, in our company, everybody knows Java, and could maintain the software if we didn't have the JNI-Layer and the IBM class library.
We have to use the C++ class library, because the IBM Java library is unusable: we get every non-printable character translated, and we lose all control characters along the way.
Now the question is: can we ditch this library and implement our solution in Java completely (we'd like to avoid using another library from another vendor)? Is the protocol well documented? Is the implementation of 3270-over-ssl really so complex?
Thanks.
https://www.rfc-editor.org/rfc/rfc1041
so i guess its documented (assuming i hit the right doc)
couldnt find a java implementation though, you'd need to code it over telnet, or maybe SSH
I am unfamiliar with the differences between 3270 and 5250 data streams, but there is a 5250 implementation in Java in the tn5250j project available from http://tn5250j.sourceforge.net/
It might be usable for you?
(also there is a 3270 screen scraping project at http://freehost3270.sourceforge.net/ but it appears to be abandoned).
freehost3270 doesn't look as abandoned as it might appear - CVS has changes from 2 years ago. There is always an arguement that good code won't need to be changed that often in any case if the requirements have not altered. There have been complimentary comments wrt to the codebase. If you don't particularly want to work with other vendors products then working with this code/project seems to be your best option.
Freehost is not good code. Do not even bother trying it. There is a reason that it seems dead. JIN TN3270 is better but is incomplete. Ideally you want to find the API that your company's Emulator software uses. I am still searching for one for ours.
Another option would be h3270. It is a Java front-end to the x3270 suite of tools.
I know this question isn't exactly a programming question, but it will affect how we program one of our products, so i guess it might be close enough.
Do you guys still see the Microsoft JVM (Java 1.1) on client computers anymore? I havent found much info on this particular JVM online...
Anyone know of a good resource to find this type of info? Sun's site is pretty much useless for this...
Thanks!
Wow, I remember this being installed on work PCs around 2002. It is not supported by Microsoft any more. See- http://www.microsoft.com/mscorp/java/default.mspx
I'd be surprised if you found many PCs that still had this on.
Haven't seen it in this millennium I think.
In my mind it would not be an unreasonable requirement to say Java 1.4 or later.
Your demographics may be different though, but I believe we talk about IE4 based systems which has been subsequenlty upgraded, and only those.
What is your product, and what does it need to do?
One way to settle a question like this would be to get hold of your company's customer list, and them out a survey. Or put a survey on your product website.
Or maybe you could buy one of those expensive "state of the industry reports" ... Gartner, etc.