Phil Rhodes

Ranch Hand
+ Follow
since Dec 27, 2003
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Phil Rhodes

Hey guys, we're working with a Struts / J2EE app on WAS 6.1, and in one of our JSP pages we try to load a plain text file with some licensing text. The file is packaged into /WEB-INF/classes/license.txt and we try to reference it using

But trying to do this fails. A co-worker who has previously looked into this said he saw something (yeah, vague I know, but this all I have to go on) which suggests it's a security policy issue. But strangely, we also load an file from the same location and it works.

This is all on WAS on Linux, if that's relevant.

Anybody have any idea what I might want to examine first on this?

12 years ago
Hi all, I'm working on a simple Eclipse plugin that should insert some text into the active editor in response to a menu command which invokes an InputDialog. Everything works, including inserting the text, but I have run into one stumbling block: I cannot figure out how to insert the text
at the current caret position.

Here is what I have so far:

Any idea how, given that, I can find the correct offset to begin my insert, based on the caret position?

[ October 08, 2007: Message edited by: Phil Rhodes ]
14 years ago

Originally posted by Abhinav Srivastava:

So ultimately what is really different in open-source java world?
It benefits the Big Corps (the way Eclipse worked out for IBM). Do you think an open source version would survive unless promoted by the Big 3/4/-5..

1. Linux / BSD distros can now ship a "real" JDK with their OS's.
2. Java loses something of it's "red headed stepchild" status in the F/OSS world.
3. possibly faster bug-fixes if the GPL license encourages more
F/OSS hacker types to get involved with Java

For probably 99.9% of Java developers this GPL'ing means absolutely nothing.
15 years ago
You'd have to be nuts to think that IBM is going to intentionally release an incompatible Java fork. And if they do, they can't call it Java, so the net effect would be the same as if IBM rolled out a brand new language tomorrow and had to start trying to get people to adopt it. Basically, it would be like MS rolling out C#.

But IBM is not in the business - for the most part - of selling proprietary programming languages and tools. They make money off hardware, middleware, services, integration and consulting. They're part of a huge ecosystem built up around Java... and you want me to believe they would intentionally try to destroy that ecosystem? No freaking way...
15 years ago

Originally posted by Jeroen T Wenting:
The exception won't help much because it is still GPL with all the dangers of getting sued that entails.
The financial damage from that (and even more importantly the damage done to your corporate image when being dragged through the dirt by the press) is very real, whether you manage to win in court on a technicallity or not.

That statement - at least in the USA - is absolute FUD. And that's because you can be sued by anybody, at anytime, for anything already. Java being GPL now means NOTHING in terms of additional risk of being sued. Nada, zilch, zero. A SCO could come along tomorrow and sue your company for violating their copyright or patent, nothing changes because of this.

And since you can be that Sun will maintain pretty tight control over the official release of the JDK, no how, no way will anybody be at any MORE risk than they already are. However much you trust Sun now to not ship something that endangers your company, you can continue to trust Sun that much tomorrow.
15 years ago
You can still create proprietary software to run on Java, you people are making way to big a deal out of this. Besides the classpath exception, I believe Sun has already said that they will continue to do binary releases of the JDK under terms that are suitable to developers of proprietary software.

I mean, stop and think about this for a minute: Sun *want* to encourage Java adoption, not discourage it. And they have very smart, very well paid lawyers analyzing this stuff... I'm sure if they thought that their license would disallow anything but GPL'd code to run on the JVM, they would not have done this.

Anyway, anybody who makes a decision to walk away from Java based on this announcement, on the strength of some arm-chair laywering, is an idiot. If you're really worried, hire a legit laywer to review the license and/or contact Sun and review things.
15 years ago
Yeah, it has a linking exception, this is no problem. It's not even 100% certain that a java VM under a pure GPL license can only be used to run GPL'd programs... but with the linking exception, it's guaranteed that you can use the VM to run anything you want.

For 99.9% of java developers, this license switch is a total non-issue.
15 years ago
I currently for for an IBM Business Partner, and have attended some IBM training, so I'll throw in what info I have...

I believe there are some discounts or special programs for Business Partners to send their employees for IBM training. Somebody already mentioned the "You pass / we pay" program, which is an example. However, I believe IBM changes their programs and entitlements fairly frequently... so if you want to find out for sure what the current scoop is, you're going to have to talk to whomever in your company is the "ibm contact" or whatever. That is, the person who gets the paperwork and stuff from the IBM partner program, and handles partner relations.

If you're interested in lots of IBM classes, look into the "IBM Education Card" program. It's a deal where you get a card for some $$$ amount (like, say $5,000 ) and that card lets you attend as many IBM training classes as you want, for one year. If you could convince $BOSS to purchase you one of those, that would be the ultimate hookup in terms of going to IBM's classes.

Also, FWIW, I found the couple of IBM classes I attended, to be fairly informative. The last one was a WebSphere Voice Server / VoiceXML class, and I learned a lot from that. Your Mileage May Vary of course.
The Servlet Specification is broken in this regard. Sharing sessions across contexts makes perfect sense, and should be allowed. Anybody game for attempting to get this changed through the JCP?
18 years ago
I agree with Andy. The difference between 1.3 and 1.4 probably isn't that important right now, and may not be for some time (if ever). FWIW, when I list my SCWCD on my resume, I don't even put the version. It just says "Sun Certified Web Component Developer" under my "Professional Certifications" section.. to the degree that the certification matters in job hunting, I think just having it period is more important in terms of getting in the door, than having a certain version. Especially since most companies probably aren't even using the newer specs yet.
Unless the company you're with now is requiring this AND requiring a certain version, I don't see any good reason to not just go ahead with the 1.3, and then later take the 1.4 if you feel the need.
I don't think you'll get a question on the real exam that
is based on that distinction (of terminology). If you should
happen to, I'd go with what the spec says...
FWIW, I don't remember any questions on my exam where that distinction would have made a difference.
it sounds like something you're trying to deserialize isn't being found on the receiving end. Is the r16 available in the classpath on the receive side?
I've had no problems using ObjectMessage before, using JBossMQ, FWIW.. but I've only mostly been sending objects that were part of the Java class library, and would therefore presumably never have any kind of classpath problem.
(old) SCWCD might be a little bit easier than SCJP, but it's not a LOT easier, IMHO. It's still a moderately challenging test... Me personally, I got the exact same score on SCWCD as I did on SCJP, FWIW.
I think it uses the lock of the object you're calling the method on.
So, if you have

when you call aMethod(), it's using the lock on object foo, IIRC. I won't swear to it, but I'm pretty sure that's right, because another thread can't enter any other synchronized method on object foo, while a thread is running inside synchronized method aMethod().