I have to design a new hardware with a uP (not determined yet) to run JavaME applications.
I've searched information about how do it, but for the moment it has been useless.
Can anyone explain how I can do it?
From what I found in my search:
- Using a uP (ARM for example) with an OS (ie: Linux) (using JIT for better performance)
- Using a uP with Jazelle. Do I have to use also an OS???
The application is an alarm control system, so it doesn't need graphical interface.
Minimal requirements are: ethernet port, 2 UARTs, SPI bus, I2C bus, min 16MB ram, min 4MB rom, IO ports.
Any suggest?
Regards,
Juanma
Since you are using JAVA application, I guess ARM926EJ (with Jazelle core) might be helpful.
What I am not sure is, why would you need a Java application for an alarm controller?
Anyway,
Step-1: Decide on the microcontroller
(ARM with Jazelle) seems to be a good
bet, considering the large number of
tool chains and eval boards already
available
Step-2: Based on your requirement
decide on an eval board from a
vendor. Most likely, the vendor will
also give you, the schematic, ported
embedded linux version with the
associated drivers
Step-3: On top of the embedded Linux
write your application
Step-4: Check the final RAM and ROM
size after you finish developing the
application
Step-5: Modify the schematics and
design your own hardware
This is normally how we develop embedded hardware ...
ARM's Jazelle page certainly implies that an underlying OS supporting Jazelle is needed. This HOW-TO article on embedded.com may help clarify things.
Good luck comes to mind. Embedded platforms can be a huge pain to develop from the ground up. Also most off-the-self micro controllers share their SPI bus with many devices making it only useful for quick short messages (don't plan on doing much else with the ethernet if you try to do webservices). I have not used any of the devices below but they looks like they might point you in the right direction.
http://www.systronix.com/
http://en.wikipedia.org/wiki/Sun_SPOT
http://www.is2t.com/en/index.php
http://www.parallax.com/tabid/517/List/0/CategoryID/13/Level/a/Default.aspx
Based on your question, here is what I believe are your requirements:
New embedded computer system
Runs Java Micro Edition applications
Question:
Do you know what Java ME configurations and profiles you need to support: CDC, CLDC, MIDP and to which version? (you say no GUI, so MIDP may not be required.)
Recommendations:
Don't try to develop your own PCB and software simultaneously. Find an embedded hardware system that has your needed peripherals and use that.
Preferably, find an embedded hardware system that comes with a royalty-free POSIX firmware layer.
Do NOT pursue Jazelle. It would be a lot of work for something you may not need. If you're running Java ME without MIDP, your performance will be satisfactory.
Related
Firstly Cheers to all PROGRAMMERS [ Today = Programmers day :) ]
Secondly,
I'm working on a project where the specifications require using a server as a front end and an application in the back end. The project is an advanced smart home system. The server will handle commands coming from the client through the internet (let's say like a remote control from outside the house) and send them (through a channel of communication) to the application (planning on using JAVA application) which will handle the main logic like controlling hardware stuff (lights ...) , reading from a microphone (local mic) and accessing a database to act as a speech recognition system (offline).
Now I'm still in the planning phase and I'm not sure which technologies are the best for this project. I'm thinking to use Node.js or Apache as the server and a JAVA application as the back end and any SQL database for the application's SRS.
I hope this illustration demonstrates clearly how the system works:
The main question is:
What is the best way to make the Java application communicate with the server (communication channel [must be bidirectional]) ?
and Do you recommend a specific server other than the mentioned ones for this job ?
What crossed my mind so far:
1- JSP and servlets (making the server is the application too). But I don't want a server to handle the offline stuff and I'm not sure if java servlets can access hardware interface. I also want the server to be separate from making critical decisions (different layer for security reasons and since it won't be used as frequently as the local [offline] system).
2- Communication channel :
A- A shared file, but it's a bad idea since I don't want the application to check if the file contents changed (command received) or not from time to time (excessive operations).
B- A an inter-process-communication through a port (socket communication) seems the best solution but I don't know how that would turn in terms of operation cost and communication errors.
OS used : Linux Raspbian
EDIT:
I'm sure ZMQ+Apache is good enough for this task, but how is it in comparison to WebServices (like SOAP) ? Would WebServices be a better solution in terms of standard implementation and security ?
All related suggestions are welcomed, TQ
ZeroMQ is great for internal communications, or any other similar communication solutions.
For specifically your case, I can see that ZeroMQ would be a best fit.
Reasons:
You offline server have to be agnostic to web solution.
Communication can be reliable and bi-directional, possibly another patterns like (pub>sub, req<>res, etc).
Restarting any of sides would not require to restart the sockets (connection) on other side, as messages are queued.
Possibility to scale not just on same hardware, but as well to local area network or even through internet.
Big community of support. It might look a bit hard to get into, but in reality it is dead simple, just go to examples and once concept understood - it is very easy and neat to work with.
ZeroMQ has lots drivers for most popular languages, that includes Java and Node.js.
Considerations:
You need to think over packets and data will be sent. So some popular data protocols like XML or JSON is good way of thinking.
Responsibilities over different services - make sure they are not dependant on each other too much. Or if main offline server - is a core of system, make sure it does not depend on web facing service, so that web face can be removed/replaced/improved etc.
Few more points to think about:
Why Java, and what about modular approach? For example if you want to expand and scale - add more sensors into smart home solutions, then having one giant application would require to change it, it is harder to maintain as well as maintain different clients with own needs. Think modular way - some core functionality for offline stuff, but many aggregator processes that would talk to different sensors. This makes easier to support different setups and environments, as well maintain the system as a whole by improving independent components.
I've been doing a lot of research on web platforms (mainly .Net vs Java), and have found that both seem to serve a lot of purposes. What I'd like to know is, does ASP.Net provide enough control, flexibility, and customization in terms of how the server hosts and runs the website, or does Java with, say, Tomcat and Swing or Struts2 offer more flexibility?
Since Tomcat is from Apache, I'd imagine that they implemented the same design and methodology which came from Apache (which I do like). I question whether or not IIS and Windows Server actually provide this sort of thing. Is my assumption correct?
Here's my own personal analysis of a comparison of the two frameworks having worked on .NET for 4 years and Java for around 5 years.
NET has a cookie-cutter like development stack. Java you have a bit more freedom. This can be a positive or a negative depending upon the developer preference. In other words, if you want to do something in .NET there is typically one standard way of doing so. This is not the case with Java where you can choose from a myriad of libraries and/or strategies to complete your task. In my opinion, Java tends to cater to a more skilled community (especially, since almost every major university teaches on Java) that has a bit more confidence and ability when designing/building applications. That is not a generalization of all Java EE vs. .NET developers as I've met equal talents in skill and ability on both platforms, I'm making a generalization of the larger community as a whole. At the end of the day, it is a harder environment to setup and run, but with that comes the added flexibility.
As far as server environments go, you can host Java EE apps on a number of servers (Tomcat, Glassfish/Apache, JBoss, etc..). Most of them open source, so if you're skilled enough, you can dig down into that code and figure out exactly what you're getting and modify it if necessary. This is absolutely not the case with the Microsoft environment. You basically have a windows server running IIS and that's pretty much it. IIS is a decent web hosting tool in my opinion. It's easy to learn the basics, however out of the box it does not have anywhere near the customization and configuration that you can setup with Apache. For example, you have to install Helicon(or some other tool) as an add-on to IIS if you want to create complex Rewrite rules for your site. Rewrite rules are easily implemented in Apache as a standard.
In conclusion, a Java web environment is harder to setup and support, but you'll get that added flexibility with your language and your server environment as you gain more knowledge.
Choosing a platform should be really about your available expertise - your own or whatever resources you (will) have.
If you know the platform you can make it fly. As #iamkrillin stated, I too have yet to hit a roadblock with IIS/.Net platform. This is true whether or not I am hosting the site myself (colo - I own hardware/OS, etc) or via a hosting provider. On Windows hosting though, choose wisely if you host. If you know you need some bare metal access then make sure you get that privilege from whomever you choose to host with. A good practice is to set your application to medium-trust while developing - unless you will go for a dedicated server, this will likely be your hosting provider's application security setting on shared/cloud environments.
As far as routing is concerned (brought up by #GeorgeMcDowd), IIS now has it bolted in, or, if you prefer to do this at the (ASP.Net) application level (instead of IIS), you can do that too (RouteTables). I don't know how complex you envision your routes will be, so I can't tell whether you will run into some limitation either of these options offer.
As far as "standard" or "cookie cutter" is concerned, I'm not actually sure what that means. You have a (massive and growing) .Net base library (from Microsoft). If you need something very specialized (and not offered by the base lib), you can scour Codeplex and other sources (too) for libraries that you can use in your application. If you use Visual Studio, you can use NuGet to do this with a few clicks.
Don't take Microsoft's stewardship of .Net lightly as well. It's consistently being improved, updated by Microsoft.
There is an area where Microsoft is critically lagging though - and that is in mobile. Against Android and IOS and their respective devices, its a tough climb for Windows (phone, Windows 8 tablet, etc.). There are however, tools that allow you to develop in .Net and push to either device. I am only personally beginning to get into that so I cannot say how perfect or disastrous it is.
Just about the only thing left is cost. Its still cheaper to host on non-Windows platforms. If you already have expertise in non-Windows platforms, then its a no-brainer. However, the hosting cost difference shouldn't be your deciding factor if you have a learning curve (that is commonly the hidden cost).
Without a specific example of what you are referring to configuration wise. I feel pretty comforable saying that there are a variety of ways to configure a website and how it is hosted/ran etc from within the IIS control panel. To that end, I have never ran into a situation where I thought "I wish I could do x with my website" and was not able to make IIS do it.
We're designing an app that will run on Windows, OSX, iOS, and Androids. It would be really nice to at least have most of the code in a single language rather than having to use Objective C for the Apple versions, C# or C++ for Windows, and Java for Android.
We were looking at Flex (with all of its problems) as a way to avoid having to use a different language for each version, but Adobe has thrown in the towel and in the long run that's not going to do the job. Java used to promise to be universal, but it looks like Apple no longer supports it as a part of the distributed OS, and as far as I can tell Microsoft never supported it. We don't want our users to have to download and install something just so they can use our app.
Is there a solution? Or are we stuck with building the app in multiple languages?
HTML + css + JavaScript!
Run your app on a standard web server. All of the above have standards compliant web browsers, all of the above support JavaScript and AJAX. The only thing that really varies is screen size and this can easily be dealt with by using a custom .css file for each target browser.
You could host a web application on a server and use the app browsers to interact with the application.
Although not a native application, all devices would be able to use it.
The downside is that server connectivity would be required, however this may not be an issue.
"global" languages are most likely to use virtual machines, so you can't escape the "users have to have to download and install something just so they can use the app"... I think Java is your best bet if you don't want to deal with problems of languages that compiles into native machine code.
You could use C# on all those platforms:
"Normal" .NET on Windows
Mono on OSX
MonoDroid on Android
MonoTouch for iOS
(If you ever wanted to write an app for Windows Phone 7, you'd be fine there too.)
Of course the UI part will have to change significantly between different platforms, and I doubt that it'll be particularly seamless, but it's worth considering at least.
i am not very sure, but i have heard python is a universal language. I have tried this with both mac and windows, not sure about the other plactforms
I believe C++ code can be run on all those platforms: Windows has full support for it; Android has NDK; and you can use Objective-C++ on iOS (and I assume OSX as well!).
I wouldn't go so far as to claim it's the best option, but I figured it was worth mentioning.
Ultimately a lot will depend on the nature of the app you are developing. If it's a large app I'd strongly suggest doing some detailed consultation with someone with experience in the area: because of the vagaries of the different platforms, this is one area where experience counts for an awful lot.
There are multiple options, depending on your app requirements:
First, Web app, as many said before. It is the same as the greatest common divisor - very small
Second Build the core of your app in c/c++, and for the interface use a framework that fits your needs. These suggestions are really, really great. You can even develop the interface separately for each platform, in Java for Android, Objective C for iOS, etc
Do not forget that never, ever you will be able to make the same code run on all platforms. There will always be some part with #define MAC or #define ANDROID. It's just impossible to run identical code, even for the simplest app.
Unless is a
void main(void){}
Even a web app will have a code like
if(browser()==Safari) {}
else {}
I think the answer depends on what kind of app you are going to build.
If it's like twitter, a good web interface is the answer. Each client just need to handle the GUI work, with the platform's own language and lib.
If it's a game, no communication with server. I prefer C and a script such as Lua to build the core of your app.
"Is there a solution? Or are we stuck with building the app in multiple languages?"
No, no solution for this. We use different languages because they run in different platforms. Universal languages, such as HTML, have lots of constrains because to be universal you must cut all the differences. It is the intersection set of all platforms, which is very very small .
Using HTML and Javascript is likely to be the best approach. Another option which runs on these platforms is Java FX 2.0.
We have a C++ application on Windows that starts a java process. These two apps need to communicate with each other (via snippets of xml).
What interprocess communication method would you choose, and why?
Methods on the table for us are: a shared file(s), pipes and sockets (although I think this has some security concerns). I'm open to other methods.
I'm not sure why you think socket-based communication would have security concerns (use SSL). It is often a very good approach as it is language agnostic, assuming that you have a well-defined communication protocol. Have a look at Google's protocol buffers, for example - they generate the required Java classes and streams.
In my experience, file systems (especially network file systems) are not well suited to such communication as they are not necessarily tuned for messaging (I've seen caching issues result in files being not picked up by the target process for example).
Another option is a messaging layer (AMQ or Tibco for example) although this will likely involve a greater administrative overhead (plus expertise) to set up.
Personally I would opt for a pure-socket approach because of its flexibility and simplicity. You will be in complete control.
I've used named pipes for communication between C# and a cross-platform c++ app and had nothing but good results. Barring that sockets is definitely the way to go.
Sockets are nice. They give you the ability to very easily create a blackbox testing layer around each component, as well as run each component on its own machine.
Security is definitely a concern, but there are a good range of options depending on how important it is. You can use SSL, custom handshaking, password protected logins and firewalls to help secure it.
Edit:
Not something I'd recommend, but there's also shared memory using JNI. Just thought I'd mention it because it's not on your list.
Ice is pretty cool :)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
What's your opinion on whether one should write an application for a specific platform or use a cross platform approach and reach more potential clients?
It would be a GUI based application and I'm thinking of using Java.
Most of the applications that I've used built on Java don't run as smooth as the native applications on the respective platforms.
The two platforms I'm thinking of are windows and macs.
If I was creating the app just for my own use, and I had to choose one system, I would choose to focus on the mac.
I would like to hear your thoughts.
I would use Qt and yes, definitely target Cross Platform...
The major reason isn't in fact what you think it is (being cross platform by itself) but actually that by targeting multiple platforms your code by some freaking weird magical reasons tends to end up with far better code quality. I've seen this happen countless times in my own projects. Every time I add a new platform the quality of the code increases and the code becomes more clean...
Also every serious app should have as few "dependencies" as possible, being cross platform means you have less dependencies... ;)
Then as a "bonus" you get to your app to run on multiple platforms...
Requirements, requirements, requirements.
In all seriousness, "it depends" is the right answer.
Truly cross platform is hard work; Working where you/your users are familiar is worth something. Solving the problem in an effective manner is really the highest priority.
Cross platform development, in general, is a bit overrated as an artform. Java is the leading technology here, but even in this case, most Java programmers don't really go cross platform. There are a few spectacular examples of tools like Vuze and LimeWire and JRipper which work pretty well just about anywhere, but these are exceptions, statistically speaking. Most Java apps, especially of the corporate variety, are coded with one platform in mind, and they never really move around.
If you want to go Mac and Windows, consider spending time in the Limewire and Vuze codebase. Both of these apps work extremely well on both platforms.
You will definetly need two builds. One build probably won't do.
I suggest to develop it first for the platform you feel comfortable with, and where you can make use of all platform gimmicks; in this case, this would be OS X.
Later, if your app is successful for the Mac, look at porting options. It's IMO not worth to put effort into porting until it is certain that there would be significant interest in the app in the first place.
In this day and age, is there really a good reason to write native code?
Yes. The languages and libraries available do not allow excellent programming to be done well. At best they allow one to write code that works ok across platforms, but never excel.
Pick one and focus on it. Focus on that audience (you'll find the audiences are different in their tastes and desires anyway).
Once you've got an app people are clamoring for on the other side, and just before someone makes a competitor, evaluate the cost/benefit to porting your finely tuned and well designed product over.
If you try to 'serve two masters' you'll make design decisions based on what's easiest for both platforms, and that's not a good design process.
-Adam
If your app uses an MVC design, you can write portable model classes using C++, and native controller and view classes for each platform you want to support. That gives you the best of both worlds - portability where that's practical, and a native interface for which your users will thank you.
I agree with your observation about Java applications versus native applications, although I'm sure that an experienced Java programmer could probably make it work.
The bottom line is that the programming APIs for both Mac and Windows are the best tools to use for building interfaces on their respective systems. If you want your app to run smoothly on a particular system, you should use that system's API.
If it is absolutely essential to have a cross-platform implementation, consider writing all of the core functionality (non user-interface portion) for your program in a library that can be compiled for both systems (c++ is an obvious choice), and then build a nice user interface for each target system that can makes calls to the common library.
IMHO, this discussion should be answer by the customer needs.
Most of the time IT provide solution, the way the solution is build is only a detail for the customer.
However making the code reusable could be useful in case your first choice of development environment was wrong.
many other criteria may come into the thinking.
for instance if your software is for health care you may want to support for 10 years, then you have to select an OS supported for more than 10 years (forget windows and mac). etc.
Depends on how much time you wish to spend on the application. Fastest way is Java, otherwise you can build your model with C++ and do separate GUI code using MFC and Cocoa.
Why don't you consider Web Application.
You can build rich UI Web site running in browser which runs everywhere and all platforms,
If you are familiar with Java, you can try GWT for the 'Weblication'
Check out the demo page of GWT
Make it a web app ?
Otherwise Java i guess. It depends of many things, type of your app, target etc.
I have had good luck with cross platform Java using SWT. This will give you a nice native-look on any OS, and there aren't a whole lot of problems out there that require any JNI code. With any luck, you should be able to distribute the exact same codebase to both targets, and it should just work.
Having said that, you should evaluate whether or not you really need the cross platform functionality. At the very least, it will require you to test the GUI layer of your app on each OS (testing layouts, presentation, etc). With a large app, this becomes cumbersome very quickly.
In either case, choosing a cross-platform language from the start will give you flexibility in the future. If you were to write native code from the start, it would be non-trivial to port the code to another platform. It would likely be accompanied by several bugs, and would also require a port of all the test code to the new platform. You would run into synchronization issues with any new features, bug fixes, etc. With Java, you can write JUnit tests which will run in both OS's, and any bugs or new features will be propogated to both versions automatically.
It really does depend on your specific application. If you are anticipating a user base on both OS's, then that should dictate your language choice.
It is possible to get a nice looking Java app to run on Windows, Linux and Java - look at SBCommander for example - and note that you can run it and look at the UI even if you don't have the hardware that it's supposed to control.
On the other hand, one thing I've found very hard to do is to write a cross-platform app that looks and behaves like a native app on each platform; there are just too many different assumptions about how an application should behave.
It really depends on who your users will be. Don't go cross-platform just because you can. There needs to be a real need regardless of the tool. And testing is going to eat up quite a bit of time. You'll still need to thoroughly test on both platforms.
I use REALbasic to create a wide variety of cross-platform desktop applications from a single code base and it has worked well for me and my clients.
Quite often I find PC developers attempt to capitalize on the Mac market (some do successfully). In turn, they development the application in the described above "cross-platform" architecture (Java, or some Qt framework, etc...) The result is usually, a hideous looking application with poor OS integration support and the community backlash commences in the reviews.
My advice, port it. Do a good job, understand your market before dumping your cross-platform product in your carpet bomb marketing approach.