Board index » jbuilder » Future development advise?

Future development advise?


2007-05-26 01:40:25 AM
jbuilder8
I am looking for some advise concerning future direction of our software
development. I work for a manufacturer that has been developing PC
based software to configure and control it's devices for 21 years. Our
current software line is all C++ Win32. Over the years we have had
requests for MAC and Linux versions of our software, but in the last few
years there has been an explosion of requests for software that will run
on a PDA or smart phone so that technicians don't have to carry a
laptop.
Because of these requests we are considering a major shift in our
development platform. Currently under consideration are C# and Java.
Pros and cons as I see them:
C# Advantages:
1. We have someone in house who has some C# experience, but not much,
and they are a new junior developer.
2. C# and the compact frame work will run on a PC or a Win CE device.
There will most likely be separate apps with the CE version being a
"lite" version, but if everything is in C# we can share a large chunk of
the tricky low level code.
C# Disadvantages:
1. Closes the door to MAC/Linux. I know there are 3rd party .NET
implementations for these platforms but I am not counting on them.
2. Won't run on non CE devices or phones (i.e. Palm, Blackberry, etc.)
3. Source code protection...
Java Advantages:
1. In theory should run on any platform that supports Java including
Windows, MAC, Linux, Win CE, Palm, Blackberry, Moto Razor...
Java Disadvantages:
1. NO Java experience. Will probably have to hire someone.
2. Concerns about how "universal" it really is. Are there a lot of
limitations that that will impact us on different platforms?
3. Source code protection...
What our software does:
1. Communicates with our devices over direct serial, modem and Ethernet
(UDP and TCP) connections. Ethernet uses AES encryption and a
proprietary protocol, NOT http.
2. Upload/download binary configuration files (50K - 100K).
3. Monitor status.
4. Send commands.
5. Update firmware. (2M - 4M now but will increase to 16M soon).
6. Read and write to local files.
7. Foreign language versions.
8. Update itself via the web.
NOTE: Not all version will do everything. For example I envision the
phone version to just be able to monitor status and send commands.
Example: I get a call about a potential problem with a unit. I can
connect to it using my Internet enabled phone and look at the status.
If it is running a little hot, I could shut it down, or adjust some
settings.
Now for the $64K question: Do you think Java is a suitable development
platform for these sort of applications?
I am interested in an unbiased opinion from someone who develops Java
apps, not just a lot of PR hype about how Java can walk on water...
 
 

Re:Future development advise?

I'll try to answer this as best I can, speaking from the perspective of
someone who works in both the C# and Java worlds...
A Nonymous wrote:
Quote
Pros and cons as I see them:

C# Advantages:

1. We have someone in house who has some C# experience, but not much,
and they are a new junior developer.
I wouldn't really count that. "Some" plus "junior" is only marginally
better than none at all (no offense intended to your developer). C#/.NET
and Java are both complex environments and it will take time to learn
enough of either platform to become productive.
Quote
2. C# and the compact frame work will run on a PC or a Win CE device.
There will most likely be separate apps with the CE version being a
"lite" version, but if everything is in C# we can share a large chunk of
the tricky low level code.
Actually, the tricky low-level code is a bit of a problem in C#, just as
it is in Java, because the environment shields you from a lot of the
low-level OS API. That being said, proper planning will allow you to use
the same low-level functions in both Win32 and CE.
Quote
C# Disadvantages:

1. Closes the door to MAC/Linux. I know there are 3rd party .NET
implementations for these platforms but I am not counting on them.
Agreed. Mono is available for Linux but isn't complete (see
www.mono-project.com/Roadmap for details). There is no Max
implementation that I'm aware of.
Quote
2. Won't run on non CE devices or phones (i.e. Palm, Blackberry, etc.)
Major drawback.
Quote
3. Source code protection...
Obfuscation is available, though I'm not sure about the quality.
Regardless of the platform (.NET, Java, C, assembly) a determined team
could take it apart. Unless you have a highly-proprietary algorithm that
is a competitive difference, I wouldn't worry about it. Most applications
are copied not by reverse engineering them but rather by examining their
functionality and rebuilding from there.
Quote
Java Advantages:

1. In theory should run on any platform that supports Java including
Windows, MAC, Linux, Win CE, Palm, Blackberry, Moto Razor...
With proper care, yes. As with CE vs. Win32, you will have to work with a
restricted API on the compact device.
Quote
Java Disadvantages:

1. NO Java experience. Will probably have to hire someone.
Not much difference than above.
Quote
2. Concerns about how "universal" it really is. Are there a lot of
limitations that that will impact us on different platforms?
I haven't done any Java mobile development, but my understanding is that
the mobile environment can vary somewhat from platform to platform, which
can make portability tricky. In the full client environments (Windows,
Linux, Mac), there isn't much visible difference between implementations
(and no API difference).
Quote
3. Source code protection...
See above.
Quote
What our software does:

1. Communicates with our devices over direct serial, modem and Ethernet
(UDP and TCP) connections. Ethernet uses AES encryption and a
proprietary protocol, NOT http.
Serial communications is a bit of a problem in Java. You'll need a
third-party library that implements the JavaComm API. The one I use quite
successfully is this: serialio.com/products/serialport/serialport.php
Serial communications support is better in .NET, but again you'd be better
off with a third-party library.
Quote
2. Upload/download binary configuration files (50K - 100K).
Not a problem in either platform.
Quote
3. Monitor status.
Not a problem in either platform.
Quote
4. Send commands.
Not a problem in either platform.
Quote
5. Update firmware. (2M - 4M now but will increase to 16M soon).
Not a problem in either platform.
Quote
6. Read and write to local files.
Not a problem in either platform.
Quote
7. Foreign language versions.
Not a problem in either platform. Internationalization is implemented a
little differently in each, but not by much.
Quote
8. Update itself via the web.
Java Web Start beats .NET ClickOnce hands down. AFAIK, however, both are
available only for the full client platforms. You'll likely need to write
your own update manager for the mobile clients.
Quote
NOTE: Not all version will do everything. For example I envision the
phone version to just be able to monitor status and send commands.

Example: I get a call about a potential problem with a unit. I can
connect to it using my Internet enabled phone and look at the status.
If it is running a little hot, I could shut it down, or adjust some
settings.

Now for the $64K question: Do you think Java is a suitable development
platform for these sort of applications?
Absolutely.
Quote
I am interested in an unbiased opinion from someone who develops Java
apps, not just a lot of PR hype about how Java can walk on water...
--
Kevin Dean [TeamB]
Dolphin Data Development Ltd.
www.datadevelopment.com/
Please see Borland's newsgroup guidelines at
info.borland.com/newsgroups/guide.html
 

Re:Future development advise?

A Nonymous wrote:
Quote
I am looking for some advise concerning future direction of our software
development.
Now for the $64K question: Do you think Java is a suitable development
platform for these sort of applications?


I am interested in an unbiased opinion from someone who develops Java
apps, not just a lot of PR hype about how Java can walk on water...

Kevin answered these questions as well as anyone could, in a manner I
would have to say was not biased.
My concerns would be centered around your statement that you are using a
non HTTP protocol for communication. Is this protocol you are using,
based on socket to socket communication or is it something else?
If sockets, you would be OK with Java or NET, although for XPlatform
outside the Windows world, I would forget NET. If you really need to
support Linux, Macs, Unix, and non MS powered PDAs, NET is going to be a
great source of frustration for you and your team.
Of course you could use WML for your embedded devices (that would
require Http however), and get part of the way with NET, but remember IE
based development does not translate well on non IE browsers. This would
include embedded browsers.
I have personally found out the hard way, that anytime you are using MS
specific tools and frameworks, rendering on non MS browsers is not
always straightforward. In fact, nothing is straightforward when you are
attempting to work with open standards (including ECMA and W3C
standards) and MS.
If you must do true Mobile development then Java 2 ME works pretty well.
However, as Kevin stated, different devices use different Java specs, so
I would definitely do my homework on those devices you plan to support
to see what type of Java implementations they have or support. Most are
attempting today to follow the J2ME standards, and most of the
differences today have to do with CDLC type concerns, But to be safe, I
would still check them out.
From what I have read of your descriptions thus far, I think I would
opt for Java for the main portions of your programs and use C/C++ for
the more low level functionality. You can call these C/C++ functions
using JNI and there are both commercial and open source options that
make JNI much easier than the SUN specifications. Look to Source Forge
for such JNI type projects and look to Excelsior Jet. Excelsior may not
run on all platforms however. The Open Source offerings may have a
higher target audience for JNI.
Although my embedded experience is not that great, I do have some
experience with it. Overall, as stated, it works pretty well with more
modern devices. If the devices you are planning to support do not
support standard J2ME, then you may have to do some code variations for
the different devices.
The majority of the time, these variations are minor, unless you plan to
use embedded databases. If you need embedded Database support, things
can get a little hairy on some devices, especially when supporting
small devices with little memory like Cell Phones.
Good Luck.
Paul
 

{smallsort}