I have a situation where I need to execute some code that for a number of reasons (that I won't get into here) is better done in Java than in PL/SQL. As I see it there are two options:
Create a jar with all my compiled code and other supporting files/other jars, load the jar into Oracle (we're running 10g), and execute the Java from a stored procedure.
Pros: The Java code integrates very nicely with the rest of the system, can be called from existing PL/SQL.
Cons: I have very little experience with running Java in Oracle.
Leave the Java in a separate jar and execute it through shell scripts.
Pros: I've written Java like this before so I'm familiar with it.
Cons: Poor integration with everything else, will probably require extra manual steps to run and manage.
The Java code will have to read XML data from Oracle tables, and write data (non-XML) to other tables, so the amount of database integration made me think loading the Java code into the database might be a good idea but I'm just not sure...
What experiences do people have loading and running Java code from within Oracle? How easy is it to test and debug? Are there are any special tools required? Any "gotchas" I should be aware of?
I would go with option number 1: loading your java code in your database. I have had good experiences with this approach and you don't need that much experience to get a good solution working with this method.
The only part where embedding Java in your database gets complicated (you'll have to set special permissions for your Java code) is when you need access to external resources (network, file i/o to name a few) and it is clearly not your situation in this problem.
For your scenario, doing it within the database seems the right approach. Reasons to do it outside could be:
dependence on Java libs that are not compatible with Oracle's built-in JVM
need to run it under a different linux user account than Oracle's
but I don't see either in your scenario
Related
I have multiple stand-alone scripts that query a database (each script queries a different source database) and insert the data into another database local to the script. Each script is scheduled via cronjob making things relatively easy and segregated. I need to combine all those scripts into one and I am looking for pointers on a design approach (assuming the one application will now run as a start-up process).
Two high-level approaches I am thinking about are:
1) Placing each script into its own package and run a pseudo-cron from main
if (time = 7pm) then run script package #1
if (time = 10 after the hour) then run script package #2
2) Place each script in its own Thread and Thread.sleep() it
Any suggestions and links to supporting documentation would be appreciated.
Thanks
this (what I am about to write) doesn't feel worthy of an "answer" but it's better than using than comments. Also, I don't have specific knowledge of either MySQL or Oracle, so this will be generic.
Reading your situations, I feel there's so much more going on here than simply 'combining scripts'.
We were given the directive to get our projects down to the minimum
number of repositories.
Is it okay to have multiple scripts in the one repo? I'm assuming here that at the very least you can have one project/folder with any number of script files in it. I'm not sure why that means you have to have one script file. And this comment...
Placing each script into its own package
...seems a bit odd - I'm not sure how you have 'one script' and 'each script in separate packages' :)
I am looking for pointers on a design approach (assuming the one
application will now run as a start-up process)
Managing (scheduling, running and monitoring) jobs is complicated to do reliably from scratch, but fortunately its a common challenge so the right tooling exists -
have you checked out the MySQL event scheduler?
If you weren't familiar with that, have a look and see if it might work for you. If it looks promising, see what guidance the docs have which might inform how you compose your scripts.
The reading and learning you do now might seem like too much effort for this specific problem, but it will pay-off in the long-term.
Can I make a Java program to generate another java application at runtime.
I want to make a "installer" program, which takes user input and generates an application as per user requirement, instead of just configuring the pre-built application according to the user needs.
I came across this solution - how to compile & run java program in another java program?, but I don't want to make clients install JDK on there computer.
Dynamically create table and Java classes at runtime -
which also need JDK, but I got a work around:
ToolProvider.getSystemJavaCompiler() returns null - usable with only JRE installed?
Can I make a complete application using above methods?
Is it a bad idea to generate such program?
Can I make Spring and Hibernate applications like that?
Or is there any existing framework for doing so?
(if possible it should create tables in db and generate html files as well. I came across http://velocity.apache.org/, so is it possible to generate java code using that.)
Your goal doesn't make a lot of sense from a practical perspective. I hope that my answer will help you to understand why.
Can I make a java program to generate another java application at runtime.
Yes you can. But it is a lot of work, especially if the application if complicated.
I want to make a "installer" program, which takes user input and generate an application as per user requirement, instead of just configuring the pre-build application according to the user needs.
That is possible ... in theory.
The problem is that you have to write a program that is capable of reading and understanding the user's requirements, and can then converting those requirements into code. Normally ... this is what a programmer does. Writing a program to do what a programmer does is not practical. (My guess is that it is 20 or more years beyond the "state of the art" of artificial intelligence to do such a thing.)
Now if the problem domain was sufficiently restricted, and the requirements were tightly specified in an unambiguous notation, then it might be feasible to do this. However, benefits of generating a program rather than configuring an existing one (based on the same requirement notation) are pretty small. And probably not worth the effort.
... but I don't want to make clients install JDK on their computer.
If you are generating Java programs you need a Java compiler. So if you insist on using a JRE (in Java 8), you need to include a 3rd party Java compiler in your application.
However, for Java 9 onward this is moot:
Oracle no longer provides JRE distributions for Java 9+ so you would need to get your client to use a 3rd-party source for their JRE.
You could (should) be using the Java 9+ jlink utility to produce a custom JRE for you application, and that can include the standard Java compiler.
If you are trying to generate code at the bytecode level, your problem is immediately ten times harder.
Sorry, I am using Java 8
Are you aware that Java 8 is "end of life" for commercial use? That is likely to affect your clients.
Can I make a complete application using above methods?
Maybe yes, maybe no. It depends on the problem domain. The more complicated it is, and the more diverse / general the requirements, the harder it will be.
Is it a bad idea to generate such program?
Yes. It is a bad idea. It is a lot more work than writing an application that is configured in the conventional way. (Noting that the configuration could include writing plugins in Java, rules in some scripting language, and so on.)
I would advise only generating source code or bytecodes if you already have a conventional application with most / all of the required functionality that you can use as a prototype for the generated generated code. (If you can't write such a prototype by hand, then writing a generator that will create one is not realistic.)
And even when it is feasible, I would question the wisdom of building a generator. There doesn't seem to be a significant pay-off for the extra effort. (For example, where is the benefit for the end user?)
Can I make spring and hibernate application like that?
I don't see why you couldn't generate such an application. But see 1) and 2).
Or is there any existing frameworks for doing so?
There are frameworks that could be used in some cases:
Templating frameworks like Velocity1 can be used to generate Java source code.
Bytecode engineering frameworks could be used to generate code directly.
1 - Indeed, I have used Velocity for Java source code generation. It worked, though I'm not convinced it was an ideal solution.
Sure you can. You can also leverage a project like GraalVM to generate native binaries for a given platform.
However, it is a lot of work, and the end result won't probably be as useful as you think. Any use case you have in mind will probably be a lot better served by an app that you just configure to do different tasks, so your efforts are probably best spent in that direction.
I have a problem where I am supposed to create an application (Preferably Java) which extracts data (Excel sheet) from onedrive account of different users and store that in a database.
I went through different resources on internet to look for the same. But i couldn't find any REST API for JAVA Applications (Although there is for Android).
Any pointers in solving above problem would be really helpful.
Thanks
Excel Datasource
As much of a fan as I am of OneDrive, it is really about storing file information not relational data. It sounds like your problem would be best solved with a connected Excel data source as seen below in this example. This will require that you setup an accessible datasource (Setting up a DB, API, or file backed source). Using the following menu should allow you to creation the relationship with the excel presentation.
Straight-forwards APIs
Assuming that you don't have the time/control needed to architect a completely new way of using this content I can give you some basic pointers around the following scenarios, 1 getting an up-to-date file from OneDrive, 2 interacting with the excel data and 3 then naturally doing what you need to do with that information.
1) Working with OneDrive
If you can interact with the file inside of your OneDrive using your machine, install the sync client for OneDrive. This will work on a Mac, Windows 7, 8, and 8.1 machine and might just get you up and syncing with ease.
If you can't use your personal account/deploy to a controlled machine you will want to use and SDK like the LiveSDK. However, I would actually recommend the Live-SDK-for-Windows, while it is not java, C# is pretty close in a lot of ways as long as you can depend on running on a windows machine.
Lastly, if you need to be able to run in a non-windows environment or have to run using the Java stack then I'd say that you should look at porting the LiveSDK-for-Android into a java only version, this is a large amount of work as you'll need to remove all the android dependencies, but you should be able to target your specific scenario around getting/updating files. You could technically look at reverse engineering how the service interactions work with a program like Fiddler.
2) Interacting with Excel files
Look around the Excel SDKs these are your best functionality bets to dig into your spreadsheets and getting the data that you'll need. There is a high likelihood that you will need to use C# or a .Net language to use them however.
Find a java compatible library to use, a quick Bing search turned up J-Integra, note that this still requires a Windows environment for execution and will have their own restrictions and usages.
I'm working on a server app that may be extended by user-supplied Groovy scripts. It's evident that I want to make sure these scripts run in a very tight sandbox where they cannot disrupt the core application code or consume too much resources to overload the server.
I have studied various possibilities and the final solution may be a combination of these:
Run the script within a very restricted security manager. The script is run within a no permission SecurityManager. Additional permissions have to be declared (like Android).
Launch a new JVM. Create a ScriptProcess wrapper around Runtime.exec and spawning a new JVM with a security manager, limited heap, etc. Because we launch a full-blown process, we might get more control on monitor bad behaving ones? The cost in resource would be dire though... An alternative would be to use Ant here, but would it be scalable?
Java Monitor API In Java 6 there is a package with monitoring capacity. We could monitor threads and maybe detect infinite loops and memory consumption. Anyone used this?
These are what I have in mind today. What would be the best way to make sure these scripts behave correctly and still keep a certain scalability and performance?
An additional possibility is using Groovy 1.8 compilation customizers on the GroovyShell that runs the embedded scripts. You can pre-import classes and methods, restrict use of the Groovy AST, and pre-apply an AST transformation, such as #ThreadInterrupt, #TimedInterrupt, or #ConditionalInterrupt. Details at:
http://www.jroller.com/melix/entry/customizing_groovy_compilation_process
You should have a look at the project groovy-sandbox from kohsuke.
Have also a look to his blog post here on this topic and what is solution is addressing: sandboxing, but performance drawback.
Also have a look at the java-sandbox project and the accompanying blog post http://blog.datenwerke.net/2013/06/sandboxing-groovy-with-java-sandbox.html.
We run batch files on our OpenVMS Alpha and Integrity servers. Up until now they have been written in COBOL. As you can imagine there are many reasons why will not be able to maintain that process.
At the same time we have a team of developers that use Eclipse and know Java very well. Is there away to use Eclipse with OpenVMS?
Maybe it's because I don't keep up with COBOL, but I am not sure why you're convinced you have to abandon it. I realize it's not the "in" thing, but if you already have a large code base I'd think at least twice before switching to another language. If it's a lack of developers, I don't think you're going to run out that soon.
That said, googling Eclipse & OpenVMS gave this link:
http://www.sdtimes.com/SearchResult/32973
So it looks like you can still get Eclipse for OpenVMS from eCube. If I'm reading that article correctly, HP seems to want you to go the NetBeans directions. Personally, I'm still using Emacs (and not currently doing any Java), so won't make a recommendation; I just wanted to point out that there are other ways to develop Java than Eclipse.
I didn't find Java for VMS on Sun's site (someone feel free to correct me if you find it), but it looks like you can get the JDK from HP/Compaq at:
http://www.compaq.com/java/download/ovms/1.5.0/index.html
Edit: I meant, but forgot to say: Assuming you're using a JVM on the VMS side, you should be able to development with Eclipse on another platform, and copy the byte code to the Alphas.
Speaking from experience, if you do decide to rewrite your batch processes in Java I'd suggest you use a third party batching framework like Spring Batch instead of 'growing your own'.
Using a framework also constrains you to work within a standard and should provide non-functional requirements like re-runability, transactions and error handling.
We've (re)built a number of batch processes from various technologies to Java using a home-grown framework and I find we end up spending time on fixing/optimizing the framework rather than just focusing on the business logic.
Don't leave Cobol yet - call a-cobol-programmer-thinking-about-switching-to-the-modern-world and make a trade: you teach him Java, He maintains your legacy.
Shell scripts and java usually aren't a great mix. You may want to consider installing a JVM on your VMS servers, and using one of the JVM-hosted languages that handle that case better- jython, jruby, or groovy might be candidates to consider.
Eclipse relies on native Java extensions that do not appear to have been ported to OpenVMS. Don't give up though. Java runs on OpenVMS (at least 1.5 according to a Google search).
NetBeans has a Java only edition that should work on OpenVMS. On the NetBeans Download Page select the OS Independent Zip option for the platform.
Are you running the batch files on your OpenVMS system? If so, HP makes Java available for OpenVMS, not SUN; you will have to look at their site. You can develop your java code on a windows/linux machine and test it on your VMS system; you must be aware of the native extensions that you cannot use on the VMS implementation of Java.
Speaking with some experience in this area, I suggest developing with Eclipse on your Windows/Linux/Mac desktop, and pushing the code out to OpenVMS for testing/deployment. Eclipse won't run on OpenVMS because of some platform-specific components of its GUI.
Some caveats:
Make sure that you are using the same version JVM on your desktop as on OpenVMS.
The case insensitivity in OpenVMS can be a problem when using inherently case-sensitive Java .class files. Package everything in a .jar and deploy it that way.
The attributes on .jar files have to be set correctly or the OpenVMS JVM can't open them. The following command should do the trick:
SET FILE *.jar /ATTR=(RFM:STMLF,RAT:CR)
HP provides both a "fast" JVM and a "classic" JVM. Use the fast VM unless your memory needs are highly variable.
I realize this question is rather old, but I was shocked nobody mentioned this book covering Java on OpenVMS.
https://www.theminimumyouneedtoknow.com/java_book.html
What really matters when using an x86 editor on OpenVMS source is your file transfer software. OpenVMS (and many other midrange ASCII based platforms) use even though most PC developers say LineFeed Carriage Return, the data files typically store it in the other order.
You can read much more about that here:
https://www.logikalsolutions.com/wordpress/information-technology/most-text-editors-get-tabs-wrong/
Your file transfer software will need to perform text mode file transfer changing the line ending characters OR your editor needs to both use and respect the better systems line ending characters. I thought there was something in Eclipse (via plug-in) to handle this. Notepadqq claims to have something.
Note this: They use Eclipse for development, not just editing.
That means they are running and debugging in their own PC based Eclipse universe and that ain't how it's going to work on OpenVMS. They are going to need a terminal into the VMS system and it needs to be a REAL VT-100 terminal emulator, not the worthless free stuff. You can read a little bit more about that here:
https://www.logikalsolutions.com/wordpress/information-technology/diamond-edt-keypad-support/
and here
https://www.logikalsolutions.com/wordpress/information-technology/xterm-and-vt-emulation/
Depending on how old your system is, you might have Pathworks installed and running. Then a system manager can create a directory for each user that they can map as a network drive to the PC. This lets the PC user use the directory like any other network disk and it generally could be configured to handle the line ending issues with text files.
There is no way they can develop on OpenVMS using Eclipse. They can edit files then test on OpenVMS, but they cannot develop within the IDE which I suspect is what they really want to do.
The only GUI that ever existed for OpenVMS was DECWindows. You had to run it on either a VAXStation or a DS model Alpha workstation. I never heard of Eclipse being ported to it. In the latest port of OpenVMS to x86 there is no GUI. It is a server only OS.
Yeah, I spent two decades on the platform and even wrote this book for it.
Yes, there is a version of Eclipse that supports OpenVMS called NXTware Remote. It has support for Java and COBOL languages as well as Fortran, Basic and Pascal.
You can edit OpenVMS files using pretty much any editor, including Eclipse - just use Samba to make OpenVMS directories and files visible to desktops on the network. If you install Java for OpenVMS, then you've got folks using Eclipse, and compiling and running on OpenVMS.
As for ditching Cobol - why? There's still a ton of companies running it, and it will certainly last for decades more.