🚀 go-pugleaf

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:

>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.

>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.

>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 
http://www.mono-project.com/Roadmap for details).  There is no Max 
implementation that I'm aware of.

>2. Won't run on non CE devices or phones (i.e. Palm, Blackberry, etc.)

Major drawback.

>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.

>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.

>Java Disadvantages:
>
>1. NO Java experience.  Will probably have to hire someone.

Not much difference than above.

>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).

>3. Source code protection...

See above.

>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: http://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.

>2. Upload/download binary configuration files (50K - 100K).

Not a problem in either platform.

>3. Monitor status.

Not a problem in either platform.

>4. Send commands.

Not a problem in either platform.

>5. Update firmware. (2M - 4M now but will increase to 16M soon).

Not a problem in either platform.

>6. Read and write to local files.

Not a problem in either platform.

>7. Foreign language versions.

Not a problem in either platform.  Internationalization is implemented a 
little differently in each, but not by much.

>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.

>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.

>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.
http://www.datadevelopment.com/

Please see Borland's newsgroup guidelines at
http://info.borland.com/newsgroups/guide.html

A Nonymous wrote:
> 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