wjw has asked for the wisdom of the Perl Monks concerning the following question:
Does anyone have experience using the Java 4.7 module? I have a potential opportunity which involves an application written for mobile apps in Java using a MySQL database. The app authors are interested in providing a web front end to the app as well. Not being a Java programmer, I thought, why not write the web portion in Perl and use the Java app to access the DB so that none of the schema information need be replicated in Perl. In other words, simply let perl handle the Web front end and use the existing Java to continue handling the back end. Am perfectly happy to have anyone with experience comment on the technical feasibility, or even the wisdom of such an approach. Thanks in advance...
...the majority is always wrong, and always the last to know about it...Insanity: Doing the same thing over and over again and expecting different results...
Re: Perl, Java, MySQL?
by Anonymous Monk on May 19, 2014 at 15:44 UTC
|
Haven't used Java, but I have tried out Inline::Java (a year or two ago), which worked well. It also has a more recent release (although only 2011) and more good reviews, and Java seems to be failing all its tests on CPAN Testers (although Inline::Java doesn't look too great either)...
As for the approach in general - you'll lose some performance in the Perl<->Java interface. If your web interface doesn't get many queries that'll likely be fine, but for a heavily used interface you may run into performance issues, and a pure Java web interface would probably be advisable.
Not duplicating the DAOs is probably a good idea, especially if they contain some code (validation?), but if the schema is simple and you're willing to have duplicate DAOs, take a look at DBIx::Class.
Also, if you haven't yet, look at Dancer, Catalyst, Mojolicious, and Mojolicious::Lite.
| [reply] |
|
| [reply] |
Re: Perl, Java, MySQL?
by jeffa (Bishop) on May 19, 2014 at 16:01 UTC
|
" I have a potential opportunity ... why not write the web portion in Perl and use the Java app to access the DB ..."
Because the folks wanting the code might want Java programmers to maintain it. What extra value does a Perl implementation provide for the requesters of this code?
| [reply] [d/l] [select] |
|
This is a point I raised with the potential. I did let them know that, were it me, I would take that route. However, the potential did ask the question, and I thought it would be in good taste to at least pursue an answer for them. I also find the concept interesting and outside my realm of experience, so decided to pursue. To answer your question, none that I see, other than they expressed an interest and I am interested in their interest... :-)
...the majority is always wrong, and always the last to know about it...Insanity: Doing the same thing over and over again and expecting different results...
| [reply] |
Re: Perl, Java, MySQL?
by dHarry (Abbot) on May 20, 2014 at 15:06 UTC
|
Hi wjw
an application written for mobile apps in Java using a MySQL database
This leaves open questions. Depending on how the application is partitioned, i.e. what runs where, and if changes can be made to server-side Java, if any.
If the app was developed with the Android SDK and it connects to a server where mySQL runs with no server-Side Java you just need a database connect:)
If there is server-side Java (there are various flavours ranging from "simple" to Enterprise Edition) there are severalways. It very much depends how it is implemented and if changes can be made to it.
Using one of the mentioned alternatives will likely lose you more than "some performance". I propose a different approach. You can easily expose Java classes as Web services and this can be integrated a lot easier!
Cheers
Harry
| [reply] |
|
Much appreciated Harry! The web services approach is exactly along the lines I was thinking. Thanks for articulating that.
What I would hope to do is let Perl handle the entire web user interface(forms, instructions, ajax calls etc...), and for data entry/manipulation, simply hand the collected results to the Web Service as you pointed out. Thus hopefully excluding the already developed access to the DB. As a result, the developers working with the main app(mobile) can modify as they wish without having to have updates to the Web front end unless there are schema additions or removals.
Again, as jeffa pointed out, it seems to make more sense to just do the whole thing in Java. On the other hand, I can imagine a scenario where the app developers may not want, or are unable, to expand their internal team and just want to outsource the web portion of the project, thus allowing them to focus completely on the mobile app. I don't know that this is the case, but it seems possible based on my experience with small companies. Thanks again for the input!
...the majority is always wrong, and always the last to know about it...Insanity: Doing the same thing over and over again and expecting different results...
| [reply] |
|
|