I accidentally used HashSet and HashMap defined under the package com.google.gwt.dev.util.collect in the client side code. Found out the package does not have a module xml file and hence these collection classes are not meant to be used on the client side.
What is the purpose of having these classes in the GWT SDK, if these aren't supposed to be used within the client package? There definitely has to be some benefit from these classes to merit inclusion in the SDK.
What am I missing?
Those collection implementations were written by Google engineers to improve the performance (specifically memory usage) of the GWT internals, such as the Java-to-JavaScript compiler. They are implementation details not intended to be part of the public API and should not be used by GWT developers.
Related
I am developing a new project with spring boot and graphql. I am confused on how to proceed because there are 2 ways to develop it, one is via the graphqls file and Annotation based approach. I prefer Annotation based approach but are they stable. exmaple : https://github.com/leangen/graphql-spqr.
I second AllirionX's answer and just want to add a few details.
Firstly, to answer your question: yes, SPQR has been pretty stable for quite a while now. Many teams are successfully using it in production. The only reason it is still in 0.X versions is the lack of documentation, but an occasional small breaking change in the API does occur.
Secondly, I'd also like to add that going code-first doesn't mean you can't also go contract-first. In fact, I'd argue you should still develop in that style. The only difference is that you get to write your contracts as Java interfaces instead of a new language.
As I highlight in SPQR's README:
Note that developing in the code-first style is still effectively
schema-first, the difference is that you develop your schema not in
yet another language, but in Java, with your IDE, the compiler and all
your tools helping you. Breaking changes to the schema mean the
compilation will fail. No need for linters or other fragile hacks.
So whether the API (as described by the interfaces) changes as the other code changes is entirely up to you. And if you need the SDL for any reason, it can always be generated from the executable schema or the introspection result.
I don't think there is a good or a bad answer to the "how to proceed" question.
There are two different approaches to build your graphql server (with graphl-java, graphql-java-tools, graphql-spqr), and each method has its advantages and inconvenients. All those library propose a springboot starter. Note that I never used graphql-spqr.
Schema first (with graphql-java or graphql-java-tools)
In this approach you first create a SDL file. The graphql library will parse it, and "all" you have to do is wire each graphql type to its data fetcher. The graphql-java-tools can even do the wiring for you.
Advantage
no need to enter into the detail of how the Graphql schema is built server side
you have a nice graphqls schema file that can be read and used by a client, easying the charge of building a graphql client
you actually define your api first (SDL schema): changing the implementation of the api will not require any change client side
Inconvenient
no compile-time check. If something is not wired properly, an exception will be thrown at runtime. But this can be negated by using graphql-java-codegen that will generate for you the java classes and interfaces for your graphql types, unions, queries, enums, etc.
if using graphql-java (no auto wiring), I felt I had to write long boring data fetchers. So I switched to graphql-java-tools.
Code first (with graphql-java or grapqhl-java-tools or graphql-spqr)
The graphql schema is built programmatically (through annotation with graphql-spqr or by building a GraphQLSchema object in graphql-java)
Advantage
compile-time check
no need to maintain both the SDL and the Domain class
Inconvenient
as your schema is generated from your code base, changing your code base will change the api, which might not be great for the clients depending on it.
This is my opinion on those different framework and I would be happy to be shown that I am in the wrong. The ultimate decision depends on your project: the size, if there is an existing code base, etc.
I'm writing scala-js frontend framework, the key feature of which is server-side rendering. The idea was that there are components that manipulate dom with document.createElement, element.appendChild and others. On the server I'd subclass HTMLDocument, Element and others, override their methods with server dom implementation that can be converted to plain string html. So I added scalajs-dom_sjs dependency to the server module and tried to do that. But HTMLDocument, Element and most likely other classes have calls to js.native inside their constructors which throw exceptions saying "use JVM version of the library". Which doesn't exist obviously. I could use the other way and implement my own dom library, but that is twice as much work, cause I'd have to implement it on server and client, while using the first approach I'd implement it only once on server.
So my question is: why is it forbidden to use scala-js library versions on server so strictly and is there a work around it?
The reason this is forbidden is that, as you noticed, the DOM API is full of js.natives. These classes are not implemented in Scala. They are part of the browser's DOM API, which does not have an equivalent on the JVM. You cannot use the types defined in scalajs-dom on the JVM and expect them to do anything useful. Where would the implementations of the methods come from?
You will indeed need to implement your own DOM-like library for the JVM side. If you do not want to "reimplement" it on the client side, you could reuse the org.scalajs.dom namespace for your classes, and give them exactly the same structure and types as in scalajs-dom (except they won't extend js.Any, obviously).
Note that this is semantically dubious. Types extending js.Any do not have the same semantics as normal Scala types. You might be able to come up with some "compatible enough" API for normal use, but it's still dubious.
Usually, to enable so-called isomorphic DOM manipulations on server and client, one would write a DOM-agnostic cross-compiling library. On the client side, it would offer a "rendering" function to actual DOM nodes; and on the server side, it would render to strings to be sent to the client in the HTML.
This is precisely what Scalatags does.
I am trying to write a Javascript client for a web application which provides a REST API to interact with the application. I want to do this in a very advanced way like with a proven stack of tools and methodologies available in Javascript.
Most of the guides about javascript client library development I found in the web are application oriented which have a view part( I mean HTML part ). What I needed is like a client library with some methods which can be used to develop web applications. So I don't want to depend this library with any other javascript library like JQuery, Backbone etc.
I have gone through lot of design patterns available in javascript, especially patterns mentioned in Learning JavaScript Design Patterns a book by Addy Osmani. And after all I got confused, I couldn't decide which one to follow.
What I have in mind is like following:
Initialize the library with some key and secret (This can be compared to declaring object for a class in php).
There will be a data persistence unit which will keep the authenticated user's identity over a predefined amount of time like sessions in php. User data will be stored in cookies or local-storage. Also there will be provisions to override the methods of this unit so that user can implement their own storage mechanism. A reference to this unit will also be passed during library initialization.
Keep a global request method which handles all the API requests associated with the library(This can be compared to a method of the main class in php)
Define all the API methods encapsulated into different units according to the area of application it dealing with. This each unit will have a constructor method which defines some default properties to the unit( This can be compared to defining models in php which will fetch or save data from the application with API ). Each of this unit can be inherited from a super unit which provides some default properties and methods.
After reading some blogs and articles I have decided to use yeoman for library development. May be I can use some yeoman community javascript library generators to start the development.
As I described above I think what I needed is like: a class which keeps a single instance throughout the application which can be used to refer all the models and functions in the models. For this may be I can go with the singleton module pattern, but I am not fully sure about how to make use of it to my requirement.
Any advice is greatly appreciated!
From the below link I understood that GWT supporting only a subset of classes or methods in the following package in client side.
java.lang
java.lang.annotation
java.util
java.io
java.sql
https://developers.google.com/web-toolkit/doc/1.6/RefJreEmulation#Package_java_lang
Why is it so?
I think it make more problem in development because I am using only GWT client and using REST Web service instead of server.
Is there any new release of jar like gwtx (new release for supporting persistence,annotation etc) for using all classes and methods in the above packages.
and my main doubt is why they are not supporting all?
To support translating Java to JavaScript, every standard class has to be emulated, i.e. recreated in such a way that the GWT compiler knows how to translate it to JavaScript. An ArrayList for instance is based around a JavaScript Array, String methods have to be emulated on top of a JavaScript String, etc.
And there are things that are simply impossible to emulate (files, sockets). A few other things are not emulated on-purpose, because the emulated version, while technically possible, would be much less performant than a more direct mapping of the browser APIs, and GWT strives for performance (third-party libraries, such as GWTx, can provide such emulations if needed) more than compatibility (the choice of Java as the language was primarily to leverage tooling, not provide a compatibility layer to allow reuse of existing libraries).
Finally, reflection is not supported as it would make it impossible for the compiler to prune dead code and do all its optimizations: how would it know that a particular class, field or method is not actually used by reflection rather than direct calls?
In short, how do you transfer semantic data between client and server with GWT and which frameworks do you use? Read on for more details that I've thought about.
For example, using GWT 2.2.0 features like the RequestFactory will bring the constraint to have java beans transferred while the semantic resources are represented as triples and a resource can have a varying set of properties. So the RequestFactory itself cannot be shaped to transfer semantic-driven data easily.
A way to do that would be to use RequestFactory with beans that represent triples. Such bean would have 3 properties: subject, predicate, object. These beans will be transferred to client which will know to query, change their properties and then send them to server. This approach will however need a custom implementation(there are no GWT-based frameworks to represent semantic data on client-side, from what I've searched so far) and that could prove buggy or unoptimized. I've seen this approach in this project: http://code.google.com/p/gwt-odb-ui/ - it used GWT-RPC and implements some classes that represent semantic resources. However, I think it's in an incipient stage so I'm reluctant to copy their model.
Also, I've found that Restlets is a framework that supports the semantic web approach to applications. However, there is no documentation or an example on how to use Restlets with Semantic Web and perhaps with GWT. Also, Restlets is also supporting GWT. Does anyone know if this is a viable solution or not?
Thank you!
Restlet should work quite well for you. It has a GWT edition able to automatically serialize your triple beans. In addition, it also comes with an org.restlet.ext.rdf extension, including a Link class similar to your triple bean idea.
For further documentation, I would suggest the "Restlet in Action" book which covers GWT and the semantic web from a Restlet and REST point of view.