Related
I am not new to software developing, but in the last years I was almost completely involved with web applications development, most likely to PHP with MySQL/PostgreSQL.
Now I am changing focus. I would like to start programming for desktop applications, with Java. The decision about language was motivated by the following reasons: it is a mature language, has space into the market, it is multiplatform, full of resources, and has some very nice IDEs (I am using netbeans 6.9).
I am not new to OOP concepts (or most of them at least), but Java has a huge gamma of solutions (technologies, frameworks and so on), and I am getting lost with that. Can't decide what is the most appropriate solution to adopt and learn from.
That said, let's get to the point. I will describe the software targets, some things I has adopted so far, and expect someone to give me some trail to follow filling the messy points.
My application is a small business application. Usual stuff about products, sales, cash management. It needs to run into a small office, with some computers (not a fully standalone desktop application). Not every user can do everything. Some would have privileges to access financial stuff, others only sell, others only fulfill products, and so on.
Per above highlevel definition, we know that it will operate like a client-server application. One server will be installed into just one machine, all others will just have the client. I am using HSQL as backend for persistence.
Would like to use Swing to build the UI (to keep theming based on the OS). Possibilities for the client include sending email (not directly, but through some already-set email client [Thunderbird, Outlook]) and printing (to any available printer in the network).
For this I am using Desktop API.
Alright, finally we got were I am loosing the grip: which framework / technology do you recommend to make development quick (pre-built forms based on the available tables), and as modular as possible?
As I said, different users would have different privileges, but instead of just checking and disabling, I would like to keep modules separated. In different packs, or something like that.
EJB? BlueJ? JavaBeans? OSGi? Swing Application Framework? I'm kinda lost with those. Any help will be appreciated.
If you're lost, keep it simple.
For the kind of desktop apps you describe, you'll need Swing and JDBC. If you switch to web, substitute JSPs written using only JSTL and servlets. You'll have to know HTML and CSS to write JSPs. You can embellish those with JavaScript as needed.
You'll go a long way with just those.
The others you mentioned are just noise until you become more comfortable:
EJBs are for enterprise scale apps. You get to leave a lot of complex stuff like threading, object pooling and lifecycle, etc. to an app server and concentrate on expressing your business logic in distributed, transactional components called Enterprise Java Beans. Not necessary to start.
BlueJ is a beginners IDE designed to shield folks from the complexities of Java. I wouldn't recommend it.
OSGi - modular deployments for web apps. Not necessary to start.
Swing App Framework? I'm not familiar with it - I don't write Swing. If you mean Spring, I think it's an excellent framework, but not necessary to start.
This is a bit off-topic, but I think it should be said anyway.
My application is a small business application. Usual stuff about products, sales, cash management. It needs to run into a small office, with some computers (not a fully standalone desktop application). Not every user can do everything. Some would have privileges to access financial stuff, others only sell, others only fulfill products, and so on.
You are attempting something very ambitious here. There are countless existing applications for doing this kind of thing for small business, some of them household names. What makes you think that you can can do better? What makes you think you can compete?
The fact that you are new to Java makes this doubly ambitious.
My advice would be:
If you have dreams of making lots of money out of this, forget it. You are >10 years too late.
If you are doing this for some client, your company or yourself to use, they / you would probably be better off using an off-the-shelf business application.
If you are doing this for "the public good", you labors would be more fruitful if you joined some existing open source business application project.
If you are just doing this "for fun" ... go for it. (This doesn't strike me as a "fun" project though ...)
Starting off with java, swing desktop app is normal... I must say though that the components included in the default, i never liked, i thought they were too ugly. https://substance.dev.java.net/
Is a look and feel lib for java.
So do your app, think it through though and make sure you have some sort of design in mind.
Its easier and often faster if you have an idea of where you're going visually than if you just start coding and hope you reach somewhere you like.
Get paper and pencil out,scribble little notes and drawings of your GUI.
You don't necessarily need frameworks and the lot, if your app will need to store data then look at the JDBC driver to connect to mysql, or have a look at embedded databases such as HSQLDB...
The application is vb.net front end and sql server express backend. The networks are always cabled LANs.
Installations are small with only a few users, none of whom would have any technical knowledge.
Very little technical support is ever called for and I'd like to keep it that way.
I don't know Java or Objective C or HTML/CSS/Javascript which as far as I can see seem to be the choices for smartphone development on Android, iphone or web based application
I want users to be able to access as much of the functionality of the application as possible for the least effort both in terms of coding and acquiring new skills on my part.
I don't know where to start or which would provide the easiest path.
I don't know how to make the database available to smartphones whilst keeping it physically secure in a small office.
If all things were equal I'd probably learn towards HTML/CSS?Javascript as it seems to be the most widely applicable.
On the other hand maybe I should wait for win phone 7?
To reach the largest number of users in a device independent manner then delivery via browser is going to give you the best results for the least effort.
If you have designed you existing application with a Data Access Layer, a Business Rules Layer and a User Interface layer, this may be as simple as creating an ASP.NET UI for mobile/internet/intranet users.
If your appliciaction is not designed this way, then my approach would be to seperate out the code in you existing into these three layers, or at the very least seperate the UI layer out of the existing code. Then it just a matter of implementing a UI layer for each access method you plan to use.
That way you end up with a lot less code to maintain, and when the businees rules or backend data changes you only have to do the change in one place for all you User Interfaces.
Well, .NET Compact Framework is already avaialbe on WinMobile, so you defenitely should give it a try if you're free to choose which mobile OS to target.
If not, I suppose that for task like this it would really be better to use web interface. If you don't now HTML/CSS/JS - as for me it's not a problem but a great chance to learn new interesting trendy things! :)
I would go with a simple html app designed for a mobile screen.
Android or iphone will only get a % of your users. If you want to get them all, you would need to write in both (and then blackberry and winmo are SOL).
So without seeing the application, it is very hard to know how much work converting vn.net to something you can get at from a web browser would be... but I don't think it would be much worse than a port to android or iphone, and it will allow a much bigger market to view.
Either way, you will need to learn something new. Learning is good though, right?
I've been developing a small card game which is called "Tarneeb". The game itself looks like Bridge card game but with different rules. Anyway, i finished the entire game as a standalone desktop application using Java 6. This is a picture of the game. Anyway, i now need to transform that into a web app with multiplayer capabilities, so the users can for an example make a new room and join existing rooms where the game is played.
Unfortunately, I have no idea on networking in Java but i searched quite a lot and i found some other Java products that may help me (JavaFX, JSP, GlassFish) but i still couldn't figure out what i exactly needed to accomplish my task. All i need right now is the direction to head to and i will do my research and hopefully learn the new skills needed.
Other answers have already pointed you to some resources.
But the biggest problem you will likely have is that it is usually impossible (or extremely time consuming up to a complete rewrite) to "add" multiplayer capabilities afterwards if you didn't plan the architecture accordingly.
As you might have a lot of interaction and a lot of updates which I should - correct me if I'm wrong - be at the client as fast as possible, I'd suggest having a look at Cometd which keeps the http connection open to each client and pushes the updates from the server to the client. If you're using jetty as webserver (and thus its "continuations") it's even highly scalable.
The thing is, there isn't one standard way of doing this which you need to read up on.
How do you want to implement this web application? As an applet? Using standard web pages? As a web start application which people have to download?
The last option would allow you to re-use most of your existing code. If you go with that option it may be worth you looking into RMI as that will probably fit in with your existing architecture.
But otherwise, as S.Lott pointed out, you need to go and learn how to make web applications before doing anything else. Those tutorials would be a good start, also you should definitely learn (X)HTML, JavaScript, and a Java web technology such as JSPs, JSF, or Struts. Exactly what you need will depend on your requirements, without more details it's diffiult to recommend one.
First, learn what a "web site" and "web application" are.
Do the tutorials: http://java.sun.com/developer/onlineTraining/index.jsp
Watch the Glassfish Tutorials: http://java.sun.com/javaee/overview/screencasts.jsp
Once you've done all the tutorials, you will have built a web application.
After you've built the tutorial web application, you can build your web application.
Web apps are very badly suited for the kind of realtime interaction you have in a card game. Yes, it can be done, but it will involve dirty hacks and you'll always have problems with high latency and broken connections. And of course you'll have to completely rewrite most of your app.
If there a possibility of running the game as a Java applet? That would make your job much easier (enable much more reuse) and the end result more usable.
There is no way to port a client based app into a web app quickly. Depending on how you want to go about it, it sounds like you either need to pursue a JSP/Javascript solution or a JavaFX solution. JavaFX actually allows for smoother (smoother than JSP/Javascript, but still going to take more than an afternoon =D ) porting of client based apps, but it has a steeper learning curve than JSP/Javascript technology in general. An interesting note here is that JavaFX isn't just a web app language. If you had coded your initial client based app in JavaFX, you would have about 50% of the work done.
JavaFX
Use Java NIO, it is quite simple and if you will grasp the basics, there would be no real need in all these countless libraries... or anyway you would know their internals. One of the important things however, mentioned here already, is that the game structure has to be adapted for networking from the start. It may be a complete rewrite in the worst case. Basically, you will have to create clients database, socket connections, and from the server side, every connection (represented by a SelectorKey object), should be encapsulated into an object, representing a "joined client". Then read/write operations would be performed to the key's socket. But there is more. The server will have to be the center of your application link, so that you will have to develop an entire network messages protocol for your game (over TCP, there is no need in UDP in this kind of game). Also - read more about the protocols (TCP/UDP/sockets, ethernet), the more you read - the better.
Also! Pay attention to the HTML5 websockets stuff. It is a great thing!!!
Alright, so I am a compsci college student who, being in college, has not branched out towards a certain specialization yet. I have been programming since I was a young teenager, certainly know my stuff - well versed in about eight different languages as well as compsci theory, etc. In addition, I have about four years of web programming (PHP mainly) behind me, having started freelance work in that area since web 2.0 became hot.
My summer job now as an intern of sorts is to write an application for an industrial, not software-related startup. This application will be used to manage production lines and logistics flow. I have chosen Java for my language because I don't want to shoot myself in the foot.
I am well-versed in the syntax of Java, in its data structures, language theory, and such, but I have absolutely no idea where to start. I can picture the program perfectly in my mind, I understand the problem clearly and got the solution's theory nailed. Namely, I have no idea what libraries to use, and am scared that they won't be well documented.
Here are some general outlines of what I'm going to make:
Two applications, one server and one
client (of which there will be many
copies).
The server and clients obviously will
communicate via (I don't know).
Both the server and the client
software will have GUIs.
The server software will have to
query a MySQL database.
The client software must be 'live' in
the sense that the GUI updates when a
change is made to the database. This
is one of the reasons why it can't be
a web application.
I'm not even sure if a framework is right for me or not. I've used MVC tons of times in my web freelance work, but I dont know how that will translate for desktop applications.
In short, I'm looking for the right libraries for the job, as well as advice on whether or not I should use a framework (and if so, which). Thanks.
This is a summer intern job? To be honest, this sounds more like a major project if you ask me. You say the start-up is not software related? Who came up with this idea? Do they have any idea of the (huge) scope that something like this might actually entail?
The business of software development is something quite different to language syntax and libraries. It's about requirements gathering, defining a spec, writing code, ensuring quality of that code, having it tested and so on. These are not things an intern should reasonably be expected to pick up. For something like this you should be under more experienced supervision, someone you can learn from, someone who has done this before.
That being said, unless there's a really good reason, I would probably do such a thing as a Website rather than a desktop app. Desktop apps are a lot more complicated in many ways. You need to code both a client and a server. Communication is a bit trickier. You have to worry about the issue of maintaining state in multiple applications, how to handle updates being pushed around and so on.
In short, it's a big job. Even a Web site is a big job but a lot of these issues go away. You could do this with Java. I've certainly coded my fair share of Java Websites but PHP might be a far simpler bet.
Also, desktop development on Java is, well, torture. Swing is (imho) tried and true but also incredibly painful to develop in. Other desktop libraries (eg Netbeans RCP, Eclipse SWT) are more modern but have other idiosyncrasies.
Desktop remoting libraries include things like Spring remoting, even Web services and other things like Burlap. For the server side, I'd be using either Tomcat or an application server (Glassfish is my preferred choice), servlets and Spring. Persistence can be done via Hibernate or Ibatis (or lots of other options).
But honestly, the desktop option is so much more complex than a Web-based one. You'd probably get a lot more done faster using PHP + jQuery + MySQL.
If you are doing this keep it as absolutely simple as possible. Try to define the absolute minimum you need to initially deliver and do that. Once someone has that they'll then have a better idea of what works for them and what doesn't. Basically it's easier to refine something that already exists vs define something that doesn't.
I recommend that you only build a web application. A web application can be 'live' in the sense you are describing it by using AJAX. It would be much easier to build just one thing. If you also want to have a rich client, then you need to build the UI in a technology you are not familiar with (like Swing or SWT) and design/implement the communication mechanism.
Have a look at Hibernate (ORM tool) and Spring (IoC framework). They have a somehow steep learning curve, but they will make your life easier at the long run. For the UI part perhaps JSF is easier for a beginner.
As a last note, I think you have an over-ambitious plan. What you are describing is not an easy project and requires expertise with a lot of technologies. Do not try to do everything in one shot.
Java Desktop 6 (JRE)
JDBC (built-in in any JRE)
MySQL JDBC drivers (freely downloadable)
for communication you have several choices: RMI (built-in) however this days I recommend
learning something like Java Web Services (JAX-RS)
Libraries?
JDBC for the database. You may want to look at ORM mechanisms like Hibernate
I would recommend the Apache Commons libraries for all your utility work (handling files, IO etc.). There's a lot of stuff there to save you reinventing the wheel.
A standard logging framework like Log4j will allow you to log in lots of different ways, filter your logs and plug into monitoring solutions easily.
You don't say whether browser-based solutions are acceptable for the client/server GUI, and that decision will drive a lot of the further architecture.
If you're looking at browser-based solutions, then I would advise a grounding in servlets regardless of any framework you ultimately choose (no doubt a lot will be recommended here).
By this stage it's getting to be a major project. Perhaps you need to concentrate on getting the fundamentals (client/server functionality) working, and worry about the GUI later. Otherwise it's a huge amount of work (and GUI work can draw an enormous amount of time).
Just one nitpicking:
Both the server and the client software will have GUIs.
I advice you to have a headless (in awt parlance) server, with an administration GUI, not a GUI-server.
Well this can go as wild as you can think of or you can go and do KISS.
If you would like something that is really simple (as in not using any frameworks):
* In the server side you can use RMI. This server side will use plain JDBC to connect to your MySQL database. But some said that this is kind of old, so if you want to get funky you can try JAX-RS which can return a JSON objects/XML to your client.
* Your client can be made using Swing (assuming you are developing desktop) or Servlet + JSP (assuming you are developing webapp) and connect to your server by calling the RMI objects/JSON objects/XML that is exposed by the server.
If you would like to get nasty which will help you in terms of code maintainability you might want to plug-in Spring + Hibernate into this application.
Good luck!
My organization has a lot of legacy ASP software on its hands.
Since our perception is that Microsoft has shown a distinct lack of support for its older products, we need to figure out what to migrate to next.
If we migrate to ASP.NET from Classic ASP, It feels like that'd be a 'complete rewrite' "migration". Since that is probably the case, we're thinking about turning to a free (as in beer and as in speech) platform. I particularly think our investment (in programming effort, I mean) would be better spent with a platform that will let us evolve, rather than forcing us to dump very single line of code every 4 / 5 years. This is the main argument we've been using to advocate moving towards a 'free' platform.
Currently we're thinking about using a mixture of Java with a dynamic language like JRuby or Groovy.
My questions are: What would be a good migration choice? Are our fears unfounded? Would we (conceivably) need to rewrite a large portion of the codebase after 4 or 5 years anyway? What arguments do you have for moving to either .NET or to a free platform?
We recently migrated a substantial ASP project to ASP.NET and it's definitely possible to do a migration that doesn't become a complete rewrite, preserving a susbstantial proportion of the original code (although we benefited from some fairly well architected code with good separation between the business logic and the presentation layers from the outset).
We looked at two possible routes to the migration:
A ground-up rewrite as a 'proper' ASP.NET application making the most of the built-in controls and shifting all of the business and data access layers into classes etc - ie the way we approach a new ASP.NET project.
A more basic syntactic migration, taking the ASP pages and changing them over to ASP.NET without making too many up-front changes to the structure or logic. Then building on that as we continue to develop the site by making better use of ASP.NET controls, separate classes etc for new and revised functionality.
Due to schedule pressures, we adopted the second route, allowing us to make the switch sooner rather than later and then take a longer-term view on more fundamental changes as part of future developments.
On that basis, for the initial migration we were able to re-use the majority of the existing code, although this is gradually being replaced as we go forward. With an 'average' page having, say, 50-200 lines of HTML and 50-500 lines of VBScript code (as separate functions, not mixed into the HTML spaghetti-style), we found it took about an hour per page to migrate them, including changing all of the ADO data access to a new ADO.NET data access layer. Some simple pages took just a few minutes - some of the more complex pages took a whole day - but about an hour a page was the overall figure across hundreds of pages, with the time to change the data access representing a significant part of the effort.
If we were to redo the migration today, we'd use ASP.NET MVC rather than web forms as it maps better to the way that the original pages were written - although I couldn't comment on whether or not a migration to MVC would take more or less time.
This doesn't necessarily have any bearing on whether or not you want to move to a free platform or change languages - you might have other reasons for wanting to do this. (Our client was Windows based so moving to ASP.NET, development time aside, carried no additional costs.) However, I can say that it's possible to migrate a substantial ASP site to ASP.NET without a complete rewrite - and it's equally possible to migrate from earlier versions of ASP.NET to more recent versions with minimal work. Obviously the route that we chose, preserving some of the ASP feel to the code rather than opting for a complete redevelopment, might not suit everyone - but it does give you a low impact entry point into ASP.NET that then allows you to build on that groundwork while making the most of your existing codebase and skills.
You know mono exists right?
I think you'll find that the longevity of a language is not as important as you think it is, since the lifetime of the major versions of an app is really quite likely to be less than that of most languages. And to be fair to .NET 2.0 -> 3.0 is a pretty small shift up, not a "dumping every single line of code" exercise. If you even wanted to shift up, which isn't really required yet.
I think a strong case could be made for any given platform you might consider, I'd look at other factors like your programmers comfort/skills/familiarity, community support, extensions, and fitness for purpose.
The choice lies in your company's ability to support whatever you choose.
Are you going to support the code yourselves? If so, what is your skill set base right now?
If you are currently enjoying ASP, ASP.NET (code rewrite or no) seems like the first idea to try, even if you don't realise it, by having used ASP thus far, you have probably acquired a great deal of knowledge in maintaining IIS, as well as the plethora of Microsoft based Services and Servers that you can reuse or at least easily adapt to, in ASP.NET development, deployment and support.
JAVA, RUBY, Whatever you choose, the beauty/usefulness/power/usability/durability of any technology lies on the people behind its maintenance.
The questions you should be making are:
best directed at your team
who will be developing, planning managing the resulting app/service?
Are you Ruby people? If not, do you want to be?
Are you JAVA people? same as above
are you....?
..and so on..
Don't distract yourselves with costs here and there or free versus non free.
when the technology is unknown/new to the people behind a project, man hours in support can be much more expensive than most packaged software solutions out there, which will then provide you with support.
This is also true for development environments where you have to pay more for the IDE/Server/etc, but on the bottom line you have less of a learning curve to go through and support at your level of expertise.
Besides: just like #annakata said, you have plenty of opportunities/projects to implement "free as in beer" ASP.NET functionality.. mono or not..
Example: you can set up ASP.NET service with Apache if you like that sort of thing..
Choose what technology you want to adopt by what you know and what you want to know, not what you think is the latest and greatest in buzz, specially if the whole reason why you even started thinking about rebuilding your code set is due to the lack of support for ASP from Microsoft.
I don't think you can escape the pain of migrating every 4-5 years given that the industry is in a continuous flux and tools, platforms and languages evolve to maximize efficiency. There's no guarantee that Groovy/Ruby/C# won't change to adopt the next big thing.
Personally I wouldn't lose sleep trying to 100% future proof myself. If that is the goal then you might as well use assembly and even then there's no guarantee that'll stay constant either.
Just consider the following
1) What do your guys know? If they are vb guys it makes sense to move to VB.NET
2) What budget do you have for tools?
3) Does the platform you want to move to have the stuff that you need? I remember some time back discovering with amazement Powerbuilder's support (or lack thereof) for regular expressions
4) Is there a community around the platform?