Related
Hi all this is my post on stackoverflow.
I am normally a lurker and find everything I need without posting but was drawing some blanks when trying to picture how this works. Maybe if someone can provide some insight I would greatly appreciate it.
So I understand the software development cycle and know a decent amount about code
(c++ and Java, and visual basic, I am a CIS major with a CS minor in my last year). I can write some programs in elipse using Java and I can even make some basic GUI components in eclipse using Java.
Now onto my 3 part question: I understand one could make a .jar from several .java files and distribute it, but while thinking about a common program like say yahoo messenger (just as an example) I came to the following three part question:
First, being could you write a program like yahoo messenger in just eclipse using Java or would you need other tools like other languages and other development environments, how does the project go from start to finish? (I think I am kind of lost here because I have only wrote command line and simple GUI applications).
Second, Say it was easier to create a feature in yahoo messenger using a different language, how can one write one program in more than one language? Say for example you wanted to write some code in python or c++ and your the majority of your code was in Java, ie your main method is java and you are compiling using JVM. (assuming you cant just stick python or c++ code in a java program) I did some Googling around and saw some things about linking the compiler and including native code to include other language code in a Java project. Links to other reading material is acceptable too if the explanation is too long.
Third- How does deployment work? Say I am done writing the code for my program and want to turn it into an .exe (for windows users) and stick it on my site for people to download. I know windows comes built in with an iexpress utility to create .exe's. Besides distributing a .jar how would one go about turning source into an exe? Thanks again for all your input and time. I am a beginner and trying to wrap my head around these concepts. The answers can be provided in a technical realm or just conceptual either is greatly appreciated.
-Mark
1) I most cases you can write your program in java without needing any other programming language. There are rather rare cases where you need to call a dll from java to interface with some proprietary program, for this you would need to use JNI and C or C++. A perhaps more common case for using multiple languages is for adding scriptability to your application. For example, my company offers a server/client application that is scriptable by users using Groovy, but the server and the rich client itself are written in Java only.
2) The integration of java and another programming language depends on the other language. Integrating Groovy is easy, and I think integrating Python (using JPython) or Ruby (using JRuby) is fairly easy. But it is an effort (not to mention the mental stress of programming in different languages) and I would not recommend doing that unless there's a specific requirement for this.
3) As always, there are several options. See how-can-i-convert-my-java-program-to-an-exe-file for creating a windows executable. Or you can create windows installer using e.g. NSIS. Or use Java Web Start.
If the intent behind this question is getting an idea how some big java rich-client (desktop) applications are written and deployed, I recommend the Eclipse RCP book. This book will walk you through the development and deployment of an XMPP/Jabber messenger client using the Eclipse RCP framework. Be aware though that there is no one true way of creating a big application and other java application frameworks do things differently.
Several IM clients are written in Java, though I would hazard a guess that the mainstream ones would be mostly written in C, C++ or (on the Mac) Objective-C.
Writing the one program in multiple languages has numerous challenges, and the nature of the challenges varies depending on the combination of languages you want to use. In many cases, you will probably not have much luck combining more than two languages. One set of impedance problems is bad enough, three is an almost guaranteed disaster.
You can avoid these problems by splitting a single application across multiple programs, each of which is written in a single language and communicates with the other programs via some kind of IPC mechanism.
Creating an "exe" is also a very language-specific concern. For instance, Java, C#, C/C++, and Python all have radically different deployment stories.
Say I am done writing the code for my program and want to turn it into an .exe (for windows users) and stick it on my site for people to download.
In that case, I'd say you were foolish. ;)
Java Web Start is a better option for deploying a Java based rich client app. from a web site. JWS works for any platform with Java.
Edit: My bad, I meant objective-c, not c#. Some reason I got it into my head it was c# the iphone used. So the answers for c# were great, thanks, but theyre a bit irrelevant, sorry about that.
I've had a look but can't find anything that answers this, though a few have shortened the question by answering parts of it. Between a small group, we were planning on doing some work on iPhone and Android, the 2 seperate for the most part but helping each other out, and with some guys doing graphics work split between them.
But we were thinking about the possibilities of moving things between the two, not necessarily apps, maybe just useful classes or something. Looking at objective-c and Java, they seem to have about the same features that the biggest obstacle would be system interface stuff, so we were wondering whether, if we created an abstraction over these on each system so they could be given the same input (which unless I'm wrong wouldn't put too much strain on the system?), would there be any problems in writing something to convert between objective-c and Java, worse than the locations of methods in the sdks? Or are there key features or something in one language that the other doesn't have which we've missed that would mean the only way to do it would be rewriting from scratch.
I wouldn't waste time trying to find commonality between iOS and Android.
Cross-platform is almost always a waste of time and resources unless the cross-platform capability is central to the apps functioning. That is especially true for platforms such as iPhone and Android which have custom OS and work very tightly with the hardware.
Cross-platform development environments add rather than reduce complexity long term. Yeah, it sounds neat but usually you get 90% what you want easily and then you hit a roadblock that destroys all the savings you made and then starts putting you in the hole. There are simply to many compromises and square pegs jammed into round holes.
Unless your app could in theory work from a generic web page, cross-platform is not for you.
In the specific case of Objective-C and Java, although Java is descended from Objective-C they have no modern interoperability. You can't use code from one on the other.
You should spend the time to learn each platform's specific API. There are no shortcuts.
Tools like XMLVM, Codename One and iSpectrum tell us that you can actually cross-compile Java code (from an Android app or creating one from scratch) to Objective-C code that is running on an iPhone without having to install any virtual machine on the Apple side of things.
I suggest watching Developing iPhone Applications using Java
Unfortunately Apple's license
agreement for the iPhone SDK prohibits
the porting of the Java virtual
machine to the iPhone. In this
presentation we introduce an Open
Source Java-to-Objective-C
cross-compiler as well as a Java-based
implementation of the Cocoa library.
With the help of these tools, iPhone
applications can be written in pure
Java. Using the Java version of Cocoa,
it is possible to run a Java-based
iPhone application as a Java
desktop/applet application that can be
cross-compiled to run natively on the
iPhone. The talk will discuss the
challenges of the Java-to-Objective-C
cross-compiler as well as the
Java-based version of Cocoa. Details
are available at http://www.xmlvm.org/
and for more insight a more recent talk about Cross-Compiling Android applications to the iPhone from Frebruary 2010 is available here, which is documented at http://www.xmlvm.org/android/ :
Android is an Open Source platform for mobile devices. Initiated by Google, Android has received much attention. Android applications are developed using Java, although a special compiler converts class files to a proprietary, register-based virtual machine that is used on Android devices to execute applications. Android defines its own API for writing mobile applications. With the help of XMLVM it is possible to cross-compile Java-based Android applications to native iPhone applications.
The Android application is written in
Java and makes use of an Android
specific API. XMLVM offers a
compatibility library, written in
Java, that offers the same API as
Android, but only makes use of the
Java-based API for Cocoa Touch. During
the cross-compilation process, both
the application and the Android
compatibility library are
cross-compiled from Java to
Objective-C and linked with the Cocoa
Touch compatibility library to yield a
native iPhone application.
From the 2008 talk about building Java applications for the iPhone http://www.xmlvm.org/iphone/ :
Apple's iPhone has generated huge
interest amongst users and developers
alike. Like MacOS X, the iPhone
development environment is based on
Objective-C as the development
language and Cocoa for the GUI
library. The iPhone SDK license
agreement does not permit the
development of a virtual machine.
Using XMLVM, we circumvent this
problem by cross-compiling Java to the
iPhone. Just like a Java application
can be cross-compiled to AJAX, XMLVM
can be used to cross-compile a Java
application to Objective-C. The
cross-compilation is also accomplished
by mimicking a stack-based machine in
Objective-C.
If you focus on abstracting away things like system interactions, and stick to the common subset of the languages, you can probably build classes that would require little or no modification to move from one language to the other.
C# does have a better implementation of generics than Java, in that C#'s generics retain strong typing at run-time.
C# also has LINQ, which as far as I know has no equivalent (yet) in Java. LINQ provides a SQL-like query capability, built into the language and fully supported by the .NET frameowrk, that lets you query object collections, and does so in a very functional-language style. LINQ can be extended by query providers to work with other data formats, such as XML and SQL, once the query provider provides an object model that translates to the other format. LINQ also makes parallelization very easy for multi-core work. It's a huge extension to language capability.
This topic is often filled with the dogma of technology jihadis, so I shall try and steer clear of that in my answer.
In my experience, I would largely agree with people saying that trying to share code between the two platforms would be difficult. However, there are some important exceptions:
I would consider cross-platform development where your business logic:
is non-trivial;
should be standardized across platforms; and
has well defined interactions with the outside world (e.g. network stack or UI).
(bonus) is written already.
Apple is the rate determining step here, given the now infamous 3.3.1 restrictions on source code languages. You can write code in Javascript according to the bundled Webkit, C, C++ and Objective C.
If you don't want to install extra languages on a 'droid, you can use the Java that compiles down to dalvik code, the Javascript as per the slightly different build of webkit or something from the NDK. Then you'll be looking at C/C++. You could cross-compile Objective-C, but I haven't had any experience of that.
The clean separation of business logic from UI and networking is important, as you'll be looking to write adapters for the networking layer, something else for the UI.
I would not attempt to write cross platform UI code in C/C++, and would either write something that used HTML/CSS/JS, or more likely write something completely custom to take advantage of the different UI metaphors on each platforms - e.g. there is no analogue to the notification bar on the iPhone. Animation on the iPhone is orders of magnitude simpler to implement than on Android.
If you don't need the UI to be massively integrated with the OS, then a webview and some HTML5 may be sufficient. Titanium is a good option here, and my colleagues in the know tell me it is better (i.e. compiles, not interpreted) than PhoneGap. Again I don't know.
Going the other way in complexity, Open GLES is available on both platforms.
It should also be noted that SVG is not available on the current crop of Android OSes.
If you actually want to do cross phone development, as long as it is not something really computationally expensive, I would probably go with PhoneGap.
PhoneGap is an open source development framework for building cross-platform mobile apps. Build apps in HTML and JavaScript and still take advantage of core features in iPhone/iTouch, iPad, Google Android, Palm, Symbian and Blackberry SDKs.
As far as I can tell, it's pretty much the only cross platform toolkit that is allowed in the iPhone app store.
If you're dead set on native development, I think you'll find that unless you're making a game and targeting c, it will be a lot of work to port. The frameworks are very different and the way of building UI is very different. That said, to answer you're direct question of objective-c vs. java, it's not that bad. It is different enough, though, that an abstraction tool would not be that easy - not like Java vs C#. Objective-c does not have garbage collection (on the iPhone anyway), for example, and the syntax is very different. Objective-c is more loosely typed in the way that it does method calls (messages in objective-c). That said, they aren't wildly different in terms of programming paradigms. They are both object oriented imperative languages. They both have classes and methods, public and private. If you wanted to port the code by hand, it wouldn't be the end of the world, I just think you might wind up spending a lot more time trying to build an abstraction layer.
If you're thinking about doing Android development my best advice is to go for java. There is no benefit at all of writing a complete abstraction (assuming you can) layer to convert from C# to Java. As for the IPhone development dont doubt about using Objective-C for the same purpose.
You can't develop for the iPhone in the same language as for Android. For the iPhone, you can only program in Objective C, it's developed by Apple. You can't use it for android, and the only way to do iPhone development is with that language (it's in the user agreement).
As for C# vs. Java, the whole principle is different. Java is one language for every platform, .Net is one platform for every language. They are not compatible. You can use Java on Android, but I'm not sure if you can use C# (.Net) as well.
Anyway, you'll have to build two different apps for these two mobile operating systems.
For the program idea I have, it requires that the software be written in one binary that is executeable by all major desktop platforms, meaning it needs an interpreted language or a language within a JVM. Either is fine with me, but the programming language has to balance power & simplicity (e.g. Python)
I know of wxPython but I have read that it's support on Mac OS X is fairly limited
Java sounds good & it looks good but it seems almost too difficult to program in
Any help?
I used Python with wxPython for quite a while and found it very easy to use. I now use Java with both Swing and SWT.
I prefer Java but that's just a personal preference so you shouldn't let that sway you.
I didn't find the transition from Python to Java that difficult. In terms of GUI, they both have the layout manager paradigm - the managers are different but not so different you'll have trouble switching.
Java has an absolute huge class library to the point where you probably don't need to write your own version of anything, just string together the components. I never really got that deep into Python but it may well be similar. One thing I did notice is that all the really good stuff I used in Python (e.g., s[-4:-1]) could still be done quite easily in Java. Both languages were a step up from C where I had to manage strings with my own libraries.
If you think wxPython is limited on MacOS, you should try Java. I run my Java code on Windows, Linux and other UNIXes without compatibility problems. Sadly, not Mac, so I can't really advise you there.
My advice, pick a smallish project - do it in both Python and Java - see how it runs on all the platforms you're interested in.
Python with PyQt or the eventually-to-be-equivalent-but-gratis PySide seems the way to go -- after all, few languages are easier to program in than Java (which you consider "almost too difficult to program in"), Python is one of those few, Qt arguably the best cross-platform GUI toolkit in any language, and PyQt (now, but GPL or for-$$$) or PySide (eventually, gratis even if you want to close-source your own code) are powerful interfaces between Python and Qt.
You can use any of languages targeting JVM, e.g. Jython (Python impl) and JRuby (Ruby impl).
You can try using Qt bindings for Python, Qt seems to support many of Mac OSX specifics.
Consider Tcl/Tk. I'm not sure how you define "one binary that is executeable [sic] by all major desktop platforms" but Tcl probably meets this as well as java, and likely better than any other scripting language.
Using the tcl packaging technology of starkits you can either a) create a single file that can be run on any platform that has an appropriate runtime engine (and they are available for all major and many minor platforms), or you can package that platform-specific runtime engine and and cross-platform starkit into a single file executable for each platform.
The starkit technology is something other languages should aspire to. What you get is a complete, fully functional virtual file system within a single file. This lets you easily package up sound files, dll/.so files (which must be copied to disk for obvious (?) reasons), images, data, etc along with your executable code.
Tk, the graphical library, is very mature and has really good support on all platforms. Some people think it looks dated but those impressions are usually based on information that is at least 5 years old. Modern Tk looks quite good. For some examples see the tkdocs website. I's not clear whether you're more concerned with eye candy or functionality, but if it's functionality you're interested in then Tk is something to seriously consider.
Most agree that Tcl is an aquired taste but those that use it professionally usually swear by it. I've been doing wxPython programming the last several months and would switch back to tcl/tk in a heartbeat if given the opportunity.
You could use Groovy to work around the Java complexities.
Still you'll need good foundations of Swing.
While the learning curve may be steep, the trade of of not having to completely re-write the whole application again for the next platform will be a good reward.
Bear in mind, that even though it is cross platform, you should consider different platforms still have different idioms ( e.g. Copy/Past in Windows is ctrl+v, ctrl+v while in Mac it is cmd+c, cmd+v )
I work on a program that has to run on Windows, Linux and OS X (and OS X is my development platform), and wxPython is what we use.
If I had a chance to start again, I'd probably go with PyQT (based on advice from friends), but wxPython will get the job done.
I think wxPython is pretty good, though I am not sure what you mean by "support on Mac OS X is fairly limited" but I have been porting a wxPython app (www.mockupscreens.com) to Mac and it wasn't that difficult with few tweaks e.g. some UI elements may not come up as you expected, as wxPython uses native UI elements, which can be an advanatage or disadvantage based on your requirements.
Other good option is PyQT which will give you consistent look on all platforms.
Java seems better for what you want.
Well what about the web application in Javascript?
How about SWT
Cross Platform
Native Look and feel
Huge community
Constantly maintained/upgraded ( IBM backed )
Atleast one mega successful cross platform project
I would suggest going the wxPython route, I know that wxWidgets (which is what wxPython is using) can be made to have great looking Mac apps (look at PgAdmin3 from postgresql). While PgAdmin3 is not done in python, it was done with wxWidgets and looks fine on a mac.
I use three cross-platform tools regularly: Realbasic from Realsoftware which is what Visual Basic v6 would have been if allowed to grow; Revolution from Runrev which is what Hypercard would have been if allowed to survive (and its neat using a scripting language whose syntax is basically English); and finally, Delphi Prism with Mono.
All are quite mature and yet expanding at a great rate. For instance, Revolution is just introducing a web-application feature to its language that is really easy to use.
Like the subject of this post suggests, I am looking at developing a suite like nero which helps burn bluray discs. I am kind of clueless as to where to start. Is there anything in Java API that lets you do this? If I were to start from scratch, would I need to start with the bluray disc spec? Are there any open source tools which are already doing this? I tried searching at sourceforge.net and found nothing useful. Any help is much appreciated.
To start with the obvious: Know your requirements and tools. I try guessing here, maybe.
Requirements:
Should burn BluRay discs
Graphical user interface
Preferred tool:
Java
Now, Java, being perhaps the prime example of a VM language from the 90es, achieves its relatively good platform-agnosticism by virtue of its VM. It's a language designed to run on a virtual hardware to ease portability to real hardware.
Now, what comes with this fact is that you abstract away many things you would have to care about, like memory-management details and architecture or platform-specifics. Among those things you can't reliably get access to is hardware. After all, you abstracted most of that away.
Now, to burn a BluRay disc you have to access hardware, in particular the BluRay writer. Not that it's impossible but Java is, in my humble opinion, not the right tool for this. You can go out of your way by implementing a library in C or C++ and using JNI/JNA to access that but looking at that, what do you really gain?
Java is usually a choice when you need a fairly modern high-level language with a large standard library and you also need your programs to run on more than one platform. Those are the primary use cases. It's not impossible with other technologies, but perhaps harder to achieve, depending on what exactly you need.
If you implement a native library to talk to the BluRay writer and talk to that from Java, then you necessarily need to re-implement it for other platforms as well (assuming that's what you want—if not, then again: Why Java?).
TL/DR version: My point is that it's not too surprising that you can't find much on exactly that topic. For one, Java wasn't really designed to do that sort of things. Most of the Java/native interop lies in the JVM and that's already an awful lot of code. Don't expect Java to natively support very rare usage scenarios such as CD/DVD/BluRay burning. Secondly, BluRay is a relatively new technology with writers not yet common hardware in computers such as CD/DVD writers, so the lack of libraries and tools may also be a mirror of the current demands of the market.
Low-level hardware access is simply not possible in pure Java unless it's in the standard API, which Bluray isn't.
Therefore, you will have to use non-Java code to access the hardware; at that point you lose the platform-independance of Java, and necessarily have a multi-language system, which is always more painful to program than using just a single language.
However, if you can find (or, I guess, develop) a multi-platform Bluray writing API or command line tool in (most likely) C, then it might still make sense to write the rest of the app in Java as a GUI wrapper with added functionality.
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.