what is best to use to create Java Desktop GUI? thanks
z*e
2 楼
用java webstart吧 不过我没用过
T*g
3 楼
swt/jface.
【在 h**k 的大作中提到】 : what is best to use to create Java Desktop GUI? thanks
t*e
4 楼
swing
h*k
5 楼
如果.net写前端,java写server是不是不错
k*r
6 楼
怎么talk呢,webservice很慢的
【在 h**k 的大作中提到】 : 如果.net写前端,java写server是不是不错
g*g
7 楼
webservice is not necesarily slow. And if it's really slow for you, consider restful service.
【在 k***r 的大作中提到】 : 怎么talk呢,webservice很慢的
k*r
8 楼
At work we provide both RMI and web service. Web service takes overall 10x-20x time as RMI. I'm not sure if all is because of webservice but I suspect it's one of the major contributors.
【在 g*****g 的大作中提到】 : webservice is not necesarily slow. And if it's really slow : for you, consider restful service.
g*g
9 楼
My experience with web service is generally pleasant, definitely not 10x slower than RMI.
【在 k***r 的大作中提到】 : At work we provide both RMI and web service. Web service : takes overall 10x-20x time as RMI. I'm not sure if all is : because of webservice but I suspect it's one of the major : contributors.
F*n
10 楼
If you have a lot of objects to send then WebService will definitely be much slower
【在 k***r 的大作中提到】 : At work we provide both RMI and web service. Web service : takes overall 10x-20x time as RMI. I'm not sure if all is : because of webservice but I suspect it's one of the major : contributors.
k*r
11 楼
Indeed. Or, if you have a series of calls to make, the latency becomes much more obvious.
much
【在 F****n 的大作中提到】 : If you have a lot of objects to send then WebService will definitely be much : slower
g*g
12 楼
You should try to use a Facade pattern to consolidate the parameters if you can.
【在 k***r 的大作中提到】 : Indeed. Or, if you have a series of calls to make, the latency : becomes much more obvious. : : much
m*t
13 楼
If by "web service" you guys mean soap, most client toolkits these days support "keep alive" connections to mitigate the latency problem. Of course being chatty is never a good practice in any rpc programming. The poor performance of soap compared to rmi could mostly be attributed to the xml marshalling cost. One project I worked on, we had huge loan objects to ship over the wire and Axis just couldn't handle it. We ended up doing binary serialization ourselves and wrapping the bytes in a soa
【在 k***r 的大作中提到】 : Indeed. Or, if you have a series of calls to make, the latency : becomes much more obvious. : : much
k*r
14 楼
What kind of problems did you have with Axis? Wrapping binaries in XML doesn't sound very efficient either to me ...
【在 m******t 的大作中提到】 : : If by "web service" you guys mean soap, most client toolkits : these days support "keep alive" connections to mitigate the : latency problem. : Of course being chatty is never a good practice in any rpc : programming. : The poor performance of soap compared to rmi could mostly : be attributed to the xml marshalling cost. One project I worked : on, we had huge loan objects to ship over the wire and Axis : just couldn't handle it. We ended up doing binary serialization
g*g
15 楼
When performance is a concern, you can always try binary protocol like hession.
【在 k***r 的大作中提到】 : What kind of problems did you have with Axis? : Wrapping binaries in XML doesn't sound very efficient : either to me ...
m*t
16 楼
One word: size. We had these huge objects, and the developers chose to give the classes and properties _real_ long names. So Each object ends up in megs after being marshalled into xml.
【在 k***r 的大作中提到】 : What kind of problems did you have with Axis? : Wrapping binaries in XML doesn't sound very efficient : either to me ...
k*r
17 楼
Thanks. It looks interesting and looks like a good fit for some binary data heavy scenarios. Do you have any experience with it?
【在 g*****g 的大作中提到】 : When performance is a concern, you can always try binary : protocol like hession.
k*r
18 楼
Tried compression before sending data on wire?
【在 m******t 的大作中提到】 : : One word: size. We had these huge objects, and the developers : chose to give the classes and properties _real_ long names. So : Each object ends up in megs after being marshalled into xml.
g*g
19 楼
Yes, we use it for our production. The good thing is that spring has built-in support for it, and it actually has C++ support too (which we never tried).
【在 k***r 的大作中提到】 : Thanks. It looks interesting and looks like a good fit : for some binary data heavy scenarios. Do you have any : experience with it?
m*t
20 楼
We could have done that perhaps by plugging code into axis and customizing the marshalling logic, but the developer in charge of it chose the easy way out. 8-)
【在 k***r 的大作中提到】 : Tried compression before sending data on wire?
k*r
21 楼
That's good to know. So you use a mixture of protocols? Or all hession?
【在 g*****g 的大作中提到】 : Yes, we use it for our production. The good thing is that : spring has built-in support for it, and it actually has : C++ support too (which we never tried).
g*g
22 楼
Of course you use a mixture of protocols. binary protocols may not work with a firewall. Usually you design it in the way that they are interchangable. If you are using spring, it may just be some different configuration on the server side.
【在 k***r 的大作中提到】 : That's good to know. So you use a mixture of protocols? : Or all hession?
k*r
23 楼
I mean, in the same application?
【在 g*****g 的大作中提到】 : Of course you use a mixture of protocols. : binary protocols may not work with a firewall. : Usually you design it in the way that they are : interchangable. If you are using spring, it may : just be some different configuration on the server : side.
g*g
24 楼
It always depends. WS is the more ubiquitous solution that can easily tunnel through firewall. RMI, Hessian etc. may be restricted on your deployment firewall settings, which may or may not be possible. We have a server that talks hessian with admin console through vpn, and WS with clients. I think you can always start with RPC style WS, like spring + CXF for minimum efforts. And seek necessary alternatives when the requirement is more clear. There's no one fit all solution.
【在 k***r 的大作中提到】 : I mean, in the same application?
m*t
25 楼
I'm not sure I would consider firewall a major issue. RMI also supports http tunneling. Hessian (normally) runs over http to begin with.
【在 g*****g 的大作中提到】 : It always depends. WS is the more ubiquitous solution : that can easily tunnel through firewall. RMI, Hessian etc. : may be restricted on your deployment firewall settings, : which may or may not be possible. : We have a server that talks hessian with admin console through : vpn, and WS with clients. I think you can always start with : RPC style WS, like spring + CXF for minimum efforts. And : seek necessary alternatives when the requirement is more clear. : There's no one fit all solution.