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.
Related
I saw some other similar questions on this topic here but they were not very helpful so I a posing this question.
What is the fastest way to convert a reasonably sized, simple web app to a Java desk top based client targeted for pc and mac? Unfortunately I can not share a whole lot of details about the app here due to various reasons. The most complicated UI in the app though is a page that contains a multi level threaded discussions (please see here for an illustrative example of what I am talking about.) The current web app is based on python so I can not re use anything from the server side code (dont think this is an issue)
I have never done any swing or awt or any other Java based thick client GUI work. My thinking is more or less defined by web based applications. I am capable of doing end to end web app development (including backend and decent UI using HTML, CSS and JS) using Java or python. For your answers please focus on Java solutions only.
So here are my questions
What is the best framework or tool I should use? I found some of the following tools on the web as part of my research.
Awt - does not look like this is a good choice.
Swing which I believe is bundled with regular Java SDK/JRE. - This may be my best
bet.
SWT which seems to compliment Swing in some fashion.
Griffon based on an article here. This framework uses Groovy ( I
have no clue about Groovy, btw) Adobe Air flex. Any open source
frameworks?
What are some of the other issues that I need to keep in mind? Some that I would like your comments on are:
How does the fact that it needs to be deployed on the client complicates things? Since we are using Java, I believe this to be a non issue. I am aware of the usual trade offs between a web based app and a desktop app (e.g. ease of deployment and upgrades etc etc.)
How easy is it to create a one click installer and bundle the app and the environment needed - eg. JRE etc?
The product needs to work on Mac and Windows. Does that complicate things in any way (Again, since it is Java I am assuming there are no gotchas but would like to be forewarned if there are any)
What is the framework or technology that may be good to have on the resume as a skill set?
My deadline is a max of 2 months - would that be enough for a reasonably simple web app given that I need to learn all of these technologies? I am just trying to get a sense here - I know it is most likely impossible to give an accurate answer - just assume I am smart enough and can pick up any unfamiliar tech stack fast enough.
Thank you!
GUI toolkit
Given "Mac and Windows", I'd say that settles my recommendation as "Swing" (perhaps with SwingX1).
I agree with your assessment of AWT. It does not support formatted text in any component out-of-the-box. It also lacks trees, tables (and other components) & people with recent experience using it. Note though, that it is also "bundled with regular Java SDK/JRE" just like Swing, it is just that it is older and less enabled than Swing generally.
If anything complements Swing it would be SwingX. SwingX is built on Swing and provides advanced controls that are not available 'out of the box' in the J2SE.
Swing and SWT are mutually incompatible - use one or the other.
I have no experience with Griffon.
Swing is the most used of the options outlined, so for getting help (ignoring other potentially important factors in the decision), it would be a good choice.
Note 1) Add SwingX if they have any groovy components that present threaded conversations easily, but I suspect a JTextPane would suffice.
Deployment
As far as deployment goes, that is a little more tricky than it seems. Many desktop computers do not come with Java as standard. Those that already have it, might have an old version.
To ensure a JRE of the right minimum version to run the app. is available, use the deployJava.js (mentioned, with links, in the JWS page below).
To provide a 'one click' launch experience for the user, look to Java Web Start.
Cross-platform gotcha's
Unfortunately, though Java is x-plat, there are plenty of things that programmers can do that stuff that up. E.G.
Not accounting for the platform default:
File encoding (file.encoding2)
Line break (line.separator2)
File separator (file.separator2)
Coding fixed size ('absolute layout') apps. that will be shown as different sized apps. on other OS.
...
Note 2. That is showing the property to use for each.
Timetable
Obviously I cannot speak for you, but I can tell you that I would have had no chance of going from 'which technology' to a 'deployable app' within two months.
Hope you're more capable than me! ;)
You said that you wanted a Java solution, but be aware that there are plenty of Gui options in Python, and you already have your web application written in Python.
Groovy is a different programming language than Java, but Groovy runs on the JVM. Do you want a Java solution or a JVM solution? I ask because you mention Griffon.
Assuming you want Java, I think your main options are Swing, SWT, JavaFX 2, and Apache Pivot. Oracle has said that they intend for JavaFX to replace Swing as the GUI platform of choice. That said, JavaFX 2 is in its infancy, and only a preview release is available for Mac right now. The upshot of JavaFX and Apache Pivot is that you could use the same code for your web application as your desktop application.
You can try doing so in small steps:
* As a first step you can create an applications with SWT and embed your application in a browser control.
* Then you should move pages and some controls from the web app to the desktop one by one.
In this way you can get a minimal application in hours :)
P.S. If you want an iOS app with this approach it's worth looking at this open source project: http://en.wikipedia.org/wiki/PhoneGap
I have to develop an ERP System for a 2,000+ end users organisation.
Could you please suggest me with comparable points that among (Java or .Net)
in which technology I should invest money and time? Although I have done
some average projects in both, but this project is going to be very big in near
future in terms of scalability.
I want to know your experiences and some tips from you people, so that I can develop
and deploy this project efficiently.
I rate .Net > Java for this project only due to less development time available.
We have to use some Rapid App Development technology.
I have to deploy this on Cloud (Azure or Google App engine).
It will be better if I got answers from those people who works in both (.Net and Java).
I will appreciate answers from your experiences.
I would suggest creating a very small proof-of-concept project in both technologies, which do something real - like allow people to log in, see messages, and allow them to type in new messages, and log out again.
Even if the project is laughably small, if you do it well, you will have a finished product on each platform which have shown you by experience how things works and if you like the way you had to do them. You will be able to see if you can debug in the cloud, if you can profile when load testing, if you can do fast work inhouse which then works well when deployed to the cloud.
And you will need to figure out things. Are the online resources good? How responsive is the StackOverflow community for each platform when you ask questions?
Personally, I consider the ".NET is Windows-only" to be important. Except for that I do not believe there is any technical showstopper for either platform.
I think both approaches can be used to deliver this successfully. I would expect you to have the same amount of success/pain with either choice. When it comes to making a decision you should base it on the amount of expertise that you have to hand. That is, your own and that of your existing colleagues and the resources that you can acquire (new recruits, contractors, consultants etc.).
That said a couple of technical notes:
The Java approach tends to have more freedom, i.e. more frameworks and choice of technologies for various solutions (although GAE will bring in some restrictions).
There is less choice in the .NET space, but that is not always a bad thing. E.g. you tend not end up in tireless debates about the logging frameworks.
Java is starting to age as a language and C# is a bit nicer, however there a number of newer languages that run on the Java VM (Scala, Groovy, Ruby, Clojure).
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.
A few years ago client Java was unsuitable for web development because a remarkable part of web users did not have Java installed. ( I don't remember exact numbers, more than 10%).
Now I see the Google Analytics stats for a big site and it tells that >98% of users have Java installed.
Is these stats very biased by Javascript usage? As I understand Google Analytics measure only users that has Javascript.
Is the picture similar on other big sites?
Does client Java have really "stopper" drawbacks compared to Flash?
EDIT: I mean java applets mainly, java WebStart seems to be not suitable for average user.
I mention Javascript only to describe the way Google Analytics works.
When I wrote my diploma project, I had to choose between Flash and Java Applets. Here are some pros and cons:
Java Applets:
[plus] you program in Java, which is mature and stable
[plus] you can use the Java GUI frameworks that pack a lot of punch
[minus] the first time the user hits the page with the applet, the JVM must be initialized and this can take up to a few minutes even on a fast computer
[minus] Applets are not meant to be used as animation media; sure, you can do stuff, but it is like programming in C - you do everything from scratch
example: i needed to show a data packet as it moved between two routers. The packet must be a control of some sort, like a button or smth. This animation can be defined in 1 line of code in Flash, where all objects derive from some base object that can be animated. I could not find a suitable solution in Java.
Flash:
[plus] really really focused on animations;
[plus] ActionScript is actually an OO language
[minus] ActionScript is sloppy, bughish and has only a few supporters. If you are stuck, be prepared to search obscure Japanese forums for solutions
[minus] ActionSCript may be OO, but it lacks a lot of features, like Enums, fully fledged interfaces, threads (!!!!) etc.
[minus] Flash was designed to be used by non-tech people - they just use the authoring tool; I wrote code for everything and it worked, but it was a pain.
My conclusion:
I eagerly await a programming paradigm for animations and rich client interfaces.
ps: Silverlight seems to be a disappointment so far, maybe Microsoft will inject some $ into it.
Mmm, Java seems to be better supported than I though, I searched some stats and found between 92 and 96% of browsers support Java (ie. it is enabled enough to detect it! although I guess lot of Java detection algorithms use JavaScript to detect & report - as you point out - but JS support is very good too anyway, even more in our Web 2.0 era).
Adobe boasts better support, but overall the difference is rather marginal. Anyway, somebody really wanting to see/use the application will activate/upgrade/download the needed engine.
Now, we have to see what JRE is supported! Alas, I didn't found any stat for that.
There, Adobe have an edge: not everybody have Flash 9 or 10, but upgrading is quite fast. While downloading and installing a new JRE is quite a bigger task... Of course, you can target the historical lowest common denominator Java 1.1, or more realistically Java 2 (1.4), but it is still frustrating not to be able to use all 1.6 features...
I have seen some people complaining that Java applets crashes their browser (apparently on Unix systems) but it is more an issue with a minor number of browsers/systems than anything else.
And as pointed out, startup time of a Java applet is quite longer than for Flash (although some big Flash games are slow to load too).
Now, I have seen a number of Processing applets, like the notorious Webpages as graphs, most of them load quickly: lot of the power is already on the hard disk of the user, in the extensive Java library. Processing generates quite lightweight jars, while lot of Flash applets must include foreign libraries... or reinvent the wheel!
Some previous postings are obsolete in regard to comments on ActionScript. ActionScript3. became available in the Flex 2 time frame, i.e., January 2007 when Flex 2.0 and Flash player 9 shipped.
AS3 is a full blown OOP programming language comparable to Java. It has classes and interfaces, inheritance, access protection keywords for class members, constructors, statics, plus some nice things that Java doesn't have: properties, events, declarative data-binding, and closures.
By default AS3 is statically compiled, hence one declares the type of members and variables. This can be relaxed to where AS3 can revert back to dynamic typing ala JavaScript. It is less efficient at runtime, though. Sometimes when dealing dynamic data it is none-the-less useful to selectively employ dynamic classes. (A nice benefit of static type checked language is code completion in the Flex Builder IDE.)
Much of Flex development is accomplished using MXML. This is a declarative XML-based DSL for Flex. MXML gets compiled into ActionScript3 code, though. So what you do in MXML is equivalent to AS3 imperative coding, but can often be more concise, clearer, and more appropriately structured with respect to the underlying graphical Flex form it represents (i.e., MXML is good for coding the views of the MVC pattern).
The bottom line is that ActionScript3 programming of Flex is easy and natural for a Java or C# programmer to learn. The language is not at all the issue. The power of Flex comes in becoming intimate with the Flex SDK and the myriad capabilities found there.
Not an exact answer, as it would be very opinionated, just sharing my experience...
In a recent project, where we were building a WAI compliant site, we were asked to avoid flash objects as accessiblity was a major issue. Applets on a different note don't go very well with most web developers ;). One reason might be the differences in the paradigms of Rich UI vs. web UI.
However, we found applets to be irreplaceable (not speaking for .NET and ActiveX controls) when client side monitoring was needed. The application uses SmartCard based authentication and applets are loaded into browser to listen for client side events (card removal) and alert the server to end session.
In this context I tend to feel that Flash is meant to be eye candy (view) where as applet though designed to be versatile, takes the role of model on client side. It is to be noted that both applets and flash consume CPU cycles on client machine, hence were traditionally suited for tasks involving lengthy computation. Calculators, Report generators, Trend illustrators, Astrological chart generators (yes) and other tasks where data can be fed by user and are results shown immediately make use of these.
A major concern involves lack of client side software (Java, flash plugins). The user experience in such cases is more than annoying.
Noticed some comments about java not updating itself. Now 1.6.0_10 is out, and it's updating itself more easily and automated than before, and you have the option of a new install method, the java kernel one. This automates the install of java components as you need them.
Some text about this: http://java.sun.com/javase/6/6u10faq.jsp
So there are changes, Sun just wakes up with the new Ceo i think. I know it's 1-2 years until this new system propagates but you can start your project and have fun when it's ready maybe. :) Who knows.
Anyway, maybe you work +500% for easy animated features than flash, but if your app is not a simple animation, then you work +500% with flash for some simple 3 line java code substitution :) Depends on your app.
I worked in Java for the last 7 years, and then I recently started on AS3 on my newest project (1.5 years and going). I love AS3 and Flash, and here's why:
The language itself is very similar to Java. The documentation at Adobe is as good or better than JavaDocs.
The AS3 language supports XML as a native type. Parsing XML in Java is a nightmare.
There are nice animation and graphics frameworks for Flash, such as papervision 3D and tweener.
If you use the Flex 3 framework and Flex Builder 3, building interfaces that look as good or better than Swing is trivial. I loved writing UIs in Swing, but designing UIs in the visual Flex Designer is like a breath of fresh air.
I'm pretty sure that there's more browser support for Flash.
Have you ever seen a Flash applet load? It has really poor usability, and makes your user click through two or three dialogs before the applet starts. Flash apps just work.
Good luck on your project!
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.