# "java import" in script **URL:** \ **Category:** Ignition\ **Tags:** scripting\ **Created:** [January 24, 2023, 7:34am UTC](https://forum.inductiveautomation.com/t/java-import-in-script/68953 "2023-01-24T07:34:38Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![nideyijuyidong](https://avatars.discourse-cdn.com/v4/letter/n/7cd45c/32.png) [@nideyijuyidong](https://forum.inductiveautomation.com/u/nideyijuyidong)\ **Post date:** [January 24, 2023, 7:34am UTC](https://forum.inductiveautomation.com/t/java-import-in-script/68953/1 "2023-01-24T07:34:38Z")
I'm a python3 programmer. I see a lot of "from java.XXX import XXX". I wonder is it a standard function in jython, or only ingition? Where should I start, is there a manual or guide? Before this, I used to use python libraries for everything. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [January 24, 2023, 1:21pm UTC](https://forum.inductiveautomation.com/t/java-import-in-script/68953/2 "2023-01-24T13:21:23Z")
Standard function in jython. With some quirks: - Wildcard imports are not supported for java packages. - Jython automatically "wraps" java objects with a dynamic subclass of `PyObject`, creating matching methods and fields. When such a wrapped object is handed to a true java method that doesn't take a PyObject, but does take the inner java type, the wrapper is automatically stripped back off. - Python native types are marshalled into similar java types. SImilar in reverse for java primitive types. Jython has a central system for managing and customizing this marshalling and unmarshalling process. See this related topic: > [@Transaction groups triggered expression item updating when trigger is false](https://forum.inductiveautomation.com/t/transaction-groups-triggered-expression-item-updating-when-trigger-is-false/17196/15): > > Thank you very much for the quick fix. Been testing this new beta on a few use cases and haven’t issued any gotchas yet slight_smile - java's `getXyz()` and `setXyz(val)` are automatically mapped to jython property `xyz` via jython's internal java machinery that implements `@property`. So both the original java methods and a python-style property become available on such "NetBeans" objects. Using the property is fewer opcodes for the jython interpreter, so should be used wherever applicable. ---
**Author:** ![nideyijuyidong](https://avatars.discourse-cdn.com/v4/letter/n/7cd45c/32.png) [@nideyijuyidong](https://forum.inductiveautomation.com/u/nideyijuyidong)\ **Post date:** [January 24, 2023, 1:52pm UTC](https://forum.inductiveautomation.com/t/java-import-in-script/68953/3 "2023-01-24T13:52:37Z")
Thanks reply. ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [January 24, 2023, 4:18pm UTC](https://forum.inductiveautomation.com/t/java-import-in-script/68953/4 "2023-01-24T16:18:22Z")
Generally speaking in Ignition, you should prefer a Java-centric approach over a Python one. The environment is the JVM, so Java libraries (including the standard library) are better maintained and supported than Jython. If you need a third party library or SDK for something, you'll also usually have a _much_ better time getting the Java code to work in Ignition than a Python library. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [August 2, 2023, 12:16pm UTC](https://forum.inductiveautomation.com/t/java-import-in-script/68953/5 "2023-08-02T12:16:01Z")
I suppose this topic is the best place to add some detail to the bullet points describing jython's java support. - Jython's wrapping operation is built around the java **class** object, which becomes a jython **type** object. In jython, a type object is how you get to a constructor, so java's class objects can be treated the same way. (There's no `new` keyword, so this is how you instantiate java in jython.) - Jython's wrapping/marshalling/unmarshalling code does a bunch of caching for performance, so once a java class's wrapper is computed, the overhead is very low. - Jython doesn't fully accommodate java's overloaded method signatures. It approximates it by differentiating by the number of function arguments, not by the argument types. If this ambiguity causes the wrong method to be called for a specific case, your only option is to use java reflection to extract exactly the method you need, and call it indirectly. - The NetBeans-style automatic property \<=\> method connection mechanism only works when the short property name doesn't clash with a method name or public field name. Those are created for the type wrapper first, and NetBeans properties cannot replace them. Keep in mind that JavaDocs are for java programmers, not jython programmers, and do not reflect jython's efforts to be helpful in this way.