Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I have java product with rich set of api. I want to write scala api as a wrapper over those java api. Are there any guidelines for the same. Please share your experience
This is a very vague question as others have noted, but I suppose there are some broad suggestions:
Use JavaConverters to translate Java collections to Scala collections.
Use Scala annotations to represent properties or characteristics represented by other means in Java. Examples of these include #deprecated, #throws, and #BeanProperty. #BeanProperty is especially useful if you want to use a library that specifically demands JavaBeans (i.e conforms to the specification).
If the Java code uses Spring, maybe look into Spring Scala if necessary. Or use more constructor-args. Or asInstanceOf to cast any beans you manually fetch from the context.
Build files. Perhaps you want to replace any Java-specific build mechanism with SBT. Or transform your Java-focused Gradle build file to be more Scala-focused. That kind of thing.
That's all I can think of. Hopefully others will point out other considerations I've missed.
Related
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 1 year ago.
Improve this question
Context: I am a novice to JVM and trying to build an app using Scala.
I was wondering, in mixed language projects (Scala/Java), for example Apache Spark, Apache Kafka, when do people choose to use Java to write a module where they already have been using Scala so far to write other modules, i.e. why those parts are not written in Scala itself?
Basically what are some example scenarios?
If for whatever reason you need to define a native java enum. Scala 2 has no syntax for defining them.
If you need an API that can be used by java programmers and you want to guarantee that not a single Scala specific feature or compilation artifact (mangled names, MODULE$ fields on objects ...) leaks out.
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 5 years ago.
Improve this question
What are the main advantages of using java cloudant client api instead of directly using the cloudant REST API?
thanks
A lot of effort has been made to ensure that the Cloudant Java library is slick to use, and hiding both some of the rough edges of the API, encoding some best practices and saving you from tedious boiler plating.
It also gives you a lot of extra functionality "for free", for example automatic retrying of requests that generated a "429: Too Many Requests" response in the rate-limited environment on IBM Cloud.
The Java library is of course also officially supported, with a regular release cadence, meaning that you can raise tickets against it, and have an expectation that issues will be fixed. As these libraries are developed in conjunction with the service, you can also expect that new features in the service will be reflected in the client libraries.
Saying all that, it's good to reflect on when to use a library that someone else wrote, and when to "roll your own". All languages and platforms tend to have good support for HTTP, and speaking directly to the API can mean that you know exactly what you have, and you can avoid any bloat, especially if you only need a fraction of what the library provides.
Here's an example I wrote (in Python, but the ideas hold for any language) to show how simple it can be to write a "micro" library yourself to target the API directly:
https://github.com/xpqz/microcdt
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 1 year ago.
Improve this question
At my work, all the Java projects so far use tools (ex: JAXB or other Json libraries) to generate Java POJOs from schemas. Can anyone tell me what the pros and cons of this approach vs writting Java domain classes by hand. Thanks
I also use JAXB at my workplace and i really find it very useful. On the very high level, the advantage of using JAXB over writing POJOs is simply what you get from an automated tool. You do not need to take the effort of doing it yourself.
I have more pros of using JAXB.
The output generated by it quite tight and efficient.
Best electronic documentation provided by JAXB download.
It gives integration with newer technologies like JAX-RS and JAX-WE.
Working on raw XML can be really tedious.
It comes bundled with Java6 or later versions.
Edit 1:
CONS: I feel we can have performance level cons as compared to other similar plugins. However, CON with respect to the alternative is that we might miss out the learning the we may get by writing it ourselves. We can definitely make a good attempt for learning if system is not so complex.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I need to implement a library which will be called from multiple languages - Java, Python, Perl and possibly more in the future. I'd hate to implement (and maintain) the same thing again and again in multiple languages.
One option I can think of is to write the core functionality in C/C++ and use SWIG to generate bindings for target languages; or maybe write the bindings myself.
Thre are some reasons why it can't be an independent service.
Are there any other mature alternatives? I am looking for options to compare before I settle for one.
Ideally, I'd like to do it using a source to source compiler or a source code generator. But I can't find one that supports all of the above languages - with potential for future additions.
I may consider any alternative binding generators if they provide any advantages over SWIG.
Thanks in advance for any pointers!
The simplest way is to write the library in C with a simple API. Every non-obscure language has some way to interface with C code.
Depending on the style of the API, SWIG can save some time in generating the bindings; but unless it's very big and regular, you might find it easier to write the bindings by hand.
Some Languages (at least Python in your question) have an FFI mechanism, that lets you write the whole binding in the target language, making it much easier to deploy and maintain. Note that most of those are focused on C APIs, not C++.
Depends on how you plan on access the library, is it possible to expose the public API via Web Services?
This way you can write the shared module in any language and access it via a common protocol such as a RESTfull web service.
Look at Microservices architecture.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
For Android app development would it be wise to use only Java, only XML, or a mixture of the two? Which option would you say is easiest or the most efficient? There seems to be more resources for Java so perhaps it would be a better option to use straight Java, but I dunno if I will be losing on out any functionality provided by XML.
I would suggest you to use both. You can completely develop only using java, but I don't think it would be possible only with xml. Because with the help of xml you can define layouts, but you cannot control the functionality of the controls. So, at that point of time java comes into picture. XML provides you a structure based and easy way of implementing UI and java provides the way of controlling and functionality for the application.
You have to use both. XML will be used for structuring the layouts of each screen. Java will pretty much be used for everything else, including ways reference and alter the functionality of the xml files.
You have to use both. Java for controller and almost XML for layout(View, dimen, color, string)
Besides, the advantage of XML is use can easily support multiscreen devices and multi-languages as well.
For support multiscreens: http://developer.android.com/guide/practices/screens_support.html